Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CAD-2000: Make the protocol era-independent #1915

Merged
merged 5 commits into from
Oct 16, 2020

Conversation

nc6
Copy link
Contributor

@nc6 nc6 commented Oct 15, 2020

Addresses https://jira.iohk.io/browse/CAD-2000

There are some additional comments in #1902 which may need to be addressed before merging.

Copy link
Contributor

@mrBliss mrBliss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic! I have been propagating Jared's branch to consensus and now everything fits nicely together 🙂

There are two problems, though (copying them from #1902). For the first one, see the inline comment about chainChecks. The second one:

We have the following class in consensus:

class ( Crypto c
      , SL.DSignable    c (OCertSignable c)
   -- , SL.DSignable    c (Hash c (TxBody era)) TODO
      , SL.KESignable   c (BHBody c)
      , SL.VRFSignable  c Seed
      ) => TPraosCrypto c

It would be a lot more convenient if that era wasn't there 🙂.

Maybe we can do something similar to what you did for the block body? I.e.:

newtype HashBBody crypto = UnsafeHashBBody {unHashBody :: (Hash crypto EraIndependentBodyHash)}

Alternatively, adding SL.DSignable (EraCrypto era) (Hash (EraCrypto era) (TxBody era)) to ShelleyBased would also well.

@@ -52,7 +52,7 @@ chainChecks ::
) =>
Globals ->
PParams era ->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consensus needs access to the PParams when calling chainChecks. Before this PR, we could extract them from the LedgerView, but that's no longer possible with this PR. Consensus doesn't have anything else in scope where it could get the PParams from.

Potential solution: create a record with the fields needed by chainChecks (_maxBHSize, _maxBBSize, _protocolVersion), let chainChecks that record as an argument and store the record in the LedgerView.

(Without a fix, the integration in consensus is broken.)

@@ -245,25 +251,52 @@ instance
initialRules = []
transitionRules = [chainTransition]

data ChainChecksData = ChainChecksData
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm open to help naming this thing...

@JaredCorduan JaredCorduan force-pushed the jc/remove-era-from-protocol branch 2 times, most recently from 0c1c9af to b505135 Compare October 16, 2020 01:48
@JaredCorduan
Copy link
Contributor

@mrBliss I've added two commits, one for each of the problems you mentioned. The second commit still has failing tests (I'm having a problem where shelley-spec-ledger-test/test/Test/Shelley/Spec/Ledger/Rules/TestChain.hs fails for me locally but not in CI, thus masking the real problems...).

  • I've added a ChainChecksData type to the LedgerView record, which contains the three (era independent!) protocol parameters needed by chainChecks. I'm not going to be winning any creative writing awards for my variable names here...
  • I have replace all the DSignable c (Hash c (TxBody era)) constraints with DSignable c (Hash c EraIndependentTxBody), and added a function eraIndTxBodyHash = coerce . hashAnnotated. I hope that this is solves the TPraosCrypto problem.

@mrBliss
Copy link
Contributor

mrBliss commented Oct 16, 2020

@JaredCorduan Thanks! I'll try them out in consensus later today.


instance Era era => FromCBOR (LedgerView era) where
instance CC.Crypto crypto => FromCBOR (LedgerView crypto) where
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, consensus doesn't need to (de)serialise LedgerView anymore, so you can get rid of these instances (and the ones for ChainChecksData too).

@mrBliss
Copy link
Contributor

mrBliss commented Oct 16, 2020

Thanks for the fixes for the two issues I brought up, I have verified that they work out well in consensus 👍. As mentioned, I would remove the To/FromCBOR instances for LedgerView and related types, because they're no longer needed and give the false impression that we're breaking binary compatibility.

@JaredCorduan
Copy link
Contributor

There was a quickcheck failure:

Ledger with Delegation
  Minimal Property Tests
    Chain and Ledger traces cover the relevant cases:                                                   FAIL (73.68s)
      *** Failed! (after 85 tests):
      Exception:
        out of bounds : -23
        CallStack (from HasCallStack):
          error, called at src/Shelley/Spec/Ledger/Coin.hs:77:15 in shelley-spec-ledger-0.1.0.0-Ml0lahSGZq7uCSKV4sLyI:Shelley.Spec.Ledger.Coin
      Use --quickcheck-replay=882383 to reproduce.

I am fairly certain that it is unrelated to this PR (our trace generators have somehow generated a negative coin). I think it makes sense to note the failure (we have the seed now) and rerun the tests.

Comment on lines 248 to 255
instance CC.Crypto crypto => FromCBOR (ChainDepState crypto) where
fromCBOR =
decodeRecordNamed
"ChainDepState"
(const 3)
( ChainDepState
<$> fromCBOR
<*> fromCBOR
<*> fromCBOR
)

instance CC.Crypto crypto => ToCBOR (ChainDepState crypto) where
toCBOR
ChainDepState
{ csProtocol,
csTickn,
csLabNonce
} =
mconcat
[ encodeListLen 3,
toCBOR csProtocol,
toCBOR csTickn,
toCBOR csLabNonce
]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, not this, we still need this 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will resurrect it! 🧟‍♂️

Comment on lines 261 to 271
instance ToCBOR ChainChecksData where
toCBOR (ChainChecksData bhs bbs pv) =
encodeListLen 3 <> toCBOR bhs <> toCBOR bbs <> toCBOR pv

instance FromCBOR ChainChecksData where
fromCBOR = do
decodeRecordNamed "ChainChecksData" (const 3) $ do
bhs <- fromCBOR
bbs <- fromCBOR
pv <- fromCBOR
pure $ ChainChecksData bhs bbs pv
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be removed, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh goodness, yes, I mistook ChainDepState for ChainChecksData. thank you @mrBliss !

Copy link
Contributor

@JaredCorduan JaredCorduan Oct 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, we are now only removing LedgerView from API/Protocol.hs, and the CBOR instances for ChainChecksData are removed from the commit that introduced them.

@JaredCorduan JaredCorduan merged commit bc0d9f4 into master Oct 16, 2020
@iohk-bors iohk-bors bot deleted the jc/remove-era-from-protocol branch October 16, 2020 17:41
iohk-bors bot added a commit to IntersectMBO/ouroboros-network that referenced this pull request Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants