Monday June 17

(team presentations)

Tuesday June 18

• CL presentation

• Set High Level CL Tasks For The Year

  • STF Outer Proof
  • Build MB Onchain: Forced Inclusion
  • Atomic Inclusion Program
  • Execution Tickets
  • Tx Aggregation
  • User TX

• Synchronous Composability would be the focus this week.

• Worked through the transaction statement (this is what reaches CL on-chain).

  

• Started Experimenting with proof systems (SP1, Nexus) in the evening, found big blockers on memory usage / proof times

Wednesday June 19

• Realized that there is a natural division in all the popular zkVM’s:
  • Stark on the inside / Snark on the outside
  • This matches very well with our inner and outer proof design for achieving sovereignty.
  • We get to bootstrap into the sovereignty architecture for free by using these VM’s
• Realized the importance of proof of equivalence in proving that a zone state commitment is equivalent to the DA blob commitment.
• We requested a machine to test proof systems without hardware constraints.

Thursday June 20

• We began running zkVM experiments on the more powerful machine that was provisioned
  • Bugs in Risc0 and SP1 prevented us from completing a full proof (only Stark proofs were completing).
  • Failed run stark_to_snark proof on Risc0
  • Bug in SP1 preventing us the from building the proof system
• Worked through the CL execution model in detail
  • Zones need minimal integration with the CL UTXO data model
  • Especially if they intend to support synchronous composability with other zones
  • This integration should not require any modification of the STF, integration lies only on the boundaries (before execution, after execution)
• Inclusion Proofs
  • We realized that inclusion proofs are a more natural mode for users to write intents instead of making claims on the output state
  • We developed a sketch of how to implement inclusion proofs using Merkle Mountain Ranges.
• We developed a sketch of a Zone supporting transfers in Risc0
  • Inclusion Proofs
  • Demonstrated how to connect an input note to an output note
• Death constraint propagation to prevent malicious executors from burning zones.
  • A solution could be that Death Constraints takes both the partial transaction and the note commitment as input to the verifier.

Friday 21