As discussed yesterday, we are going to build our own data availability
mechanism for signed VAAs, which will be specified in a new design doc.
This means that we can simplify our existing design:
- The special role of Solana as a fancy K/V store is eliminated
along with the postVAA method. The Solana smart contract is now
identical to all other chain contracts in terms of functionality.
- We no longer need optional persistence - our own data availability
layer will not be limited by on-chain performance considerations,
so we can simply persist all messages.
- Submission of VAAs to Solana now happens entirely client-side.
Guardians no longer need to run the separate agent or spend SOL.
Change-Id: I1ec755803731796b70a546868c5ba5bc032b02e5
This allows requesting attestations for various commitment/confirmation levels. This is helpful for low-latency applications like Pyth.
Change-Id: Ib49ace163365106b227613d2f66b787b3e5f5461