You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the course of refactoring the block validation flow as a preparation to multithreading, there are been several issues linked to Nim type system (type, typedesc, auto) and working with types in macros (nim-lang/RFCs#44).
Given the timesink they are, we will instead use dumb code duplication for now.
typeTrustLevel*=enum## The trust level of a block, attestation or signature#### When we receive blocks from outside sources, they are untrusted and go## through several layers of validation. Blocks that have gone through## validations can be trusted to be well-formed, with a correct signature,## having a parent and applying cleanly to the state that their parent## left them with.#### When loading such blocks from the database, to rewind states for example,## it is expensive to redo the validations (in particular, the signature## checks), thus `TrustedBlock` uses a `TrustedSig` type to mark that these## checks can be skipped.#### docs/block_validation_flow.mdUnchecked# Object hasn't gone through any verificationSigVerified# Object cryptographic signature has been verifiedTransitionVerified# Object is valid according to the protocol state transition logicTrusted# Object is fully verified both cryptographically and logically#TODO: we might want to compile with deduplication on# as the C code will be the same but we will have 1 duplicate per trust level# https://stackoverflow.com/questions/15168924/gcc-clang-merging-functions-with-identical-instructions-comdat-folding# linker: --icf (identical COMDAT folding)# GCC: -ffunction-sectionsAttestation*[Trust: staticTrustLevel] =object
aggregation_bits*: CommitteeValidatorsBits
data*: AttestationDatawhenTrustin {SigVerified, Trusted}:
signature*: TrustedSigelse:
signature*: ValidatorSig
Instead Tags using generics were used 0a0a304, the logic compiled and passed tests but quickly compiler crashes appear in our SSZ serialization
Changes were added so that testutils didn't require SSZ all the time adding more noise to find out what was wrong and what worked d78b945
Part of the EF tests were made working, those that didn't involve generics 6df6931
Compiler crashes are addressed in 5 and due to the Nim compiler.
The runtime error is addressed in 6 and due to the when not being properly accounted for offset computation.
Additional hacks to support when statement within an object declaration were needed or the serialization offsets were wrong: status-im/nim-serialization@dfd6e34 (note that this one is on us, Nim fieldPairs properly skips the wrong when instantiation, but we might need better macro tools to work with that).
Then additional fixes when the when branches reuse the same name status-im/nim-serialization@4e2ffe3 it relies on when compiles using the fact that on the wrong branch the type will be wrong.
Unfixed, the recordFields macro in stew/shims doesn't save instantiated generics and in some cases return the abstract generic type instead of the instantiated one. There is an attempt to monkey patch around that in nim-serialization status-im/nim-serialization@82cdd5c.
It mostly works, except when getTypeInst decides to return a dumb symbol instead of the type we actually want for unknown reason. while the previous type worked just fine . This workaround also required working around getImpl on types return incorrect tree in when branches nim-lang/Nim#16639
The text was updated successfully, but these errors were encountered:
nim-ssz-serialization has been significantly refactored since, specifically to avoid fancy generics, import order issues and other stuff - closing this for now, I don't think there's anything actionable based on today's codebase and compiler version other than what is tracked elsewhere.
In the course of refactoring the block validation flow as a preparation to multithreading, there are been several issues linked to Nim type system (type, typedesc, auto) and working with types in macros (nim-lang/RFCs#44).
Given the timesink they are, we will instead use dumb code duplication for now.
The code is stashed in this commit 798e135 and requires this commit/branch to nim-serialization status-im/nim-serialization@82cdd5c.
A recap on difficulties encountered and their status:
They caused visibility issues with chronicles.
6df6931
Compiler crashes are addressed in 5 and due to the Nim compiler.
The runtime error is addressed in 6 and due to the
when
not being properly accounted for offset computation.when
branches reuse the same name status-im/nim-serialization@4e2ffe3 it relies onwhen compiles
using the fact that on the wrong branch the type will be wrong.recordFields
macro in stew/shims doesn't save instantiated generics and in some cases return the abstract generic type instead of the instantiated one. There is an attempt to monkey patch around that in nim-serialization status-im/nim-serialization@82cdd5c.It mostly works, except when getTypeInst decides to return a dumb symbol instead of the type we actually want for unknown reason.
while the previous type worked just fine
. This workaround also required working around
getImpl
on types return incorrect tree inwhen
branches nim-lang/Nim#16639The text was updated successfully, but these errors were encountered: