SHARE
TWEET

Untitled

a guest Apr 30th, 2017 99 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. [Vitalik Buterin] so, here's the right way to think about it
  2. [Vitalik Buterin] on every shard, you have a "shard state", call it s[i]
  3. [Vitalik Buterin] the state transition function takes as input s[i] and a collation on shard i and outputs s'[i]
  4. [Vitalik Buterin] note that post-serenity the goal is that all transactions are valid; transactions that do stuff that we'd consider wrong like spending money that doesn't exist simply have no effect
  5. [Vitalik Buterin] this creates a nice clean separation between state transition computation and data availability verification
  6. [Vitalik Buterin] now, a "collation object" would be of the form (prevstate, collation_root, poststate)
  7. [Vitalik Buterin] a collation can only be invalid if either (i) the collation root points to data that's malformatted, or (ii) the poststate does not follow from the prevstate
  8. [Vitalik Buterin] there is cross-shard communication, but that deliberately has a delay
  9. [Vitalik Buterin] specifically, we expand the state transition function slightly
  10. [Vitalik Buterin] so it also has access to *receipts created in other shards from the previous dynasty*
  11. [Vitalik Buterin] this is important
  12. [Vitalik Buterin] as it means that the only cross-shard state that state transitions can depend on is state that is already finalized
  13. [Vitalik Buterin] as dynasty changes imply finality
  14. [Vitalik Buterin] in practice, this means that cross-shard communication will have a lag of ~30-60 min
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!
 
Top