design: remove message persistence on Solana
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 commit is contained in:
Leo
parent
bb8c1a312f
commit
349bf24937
|
|
@ -61,7 +61,7 @@ following problems, leaving them for future design iterations:
|
|||
|
||||
- The specifics of implementing applications, other than ensuring we provide the right APIs.
|
||||
|
||||
- Data availability on chains other than Solana. Delivering the signed message to the target chain is up to the
|
||||
- Data availability/persistence. Delivering the signed message to the target chain is up to the
|
||||
individual application. Possible implementations include client-side message retrieval and submission, like the
|
||||
current Wormhole implementation does for delivering transfer messages on Ethereum, or message relays.
|
||||
|
||||
|
|
@ -74,8 +74,7 @@ following problems, leaving them for future design iterations:
|
|||
|
||||
We simplify the design of Wormhole to only provide generic **signed attestations of finalized chain state**.
|
||||
Attestations can be requested by any contract by publishing a message, which is then picked up and signed by the
|
||||
Wormhole guardian set. The signed attestation will be published on the Wormhole P2P network and - if requested by the
|
||||
message publisher - be persisted, but not executed, on Solana for data availability.
|
||||
Wormhole guardian set. The signed attestation will be published on the Wormhole P2P network.
|
||||
|
||||
Delivering the message to a contract on the target chain is shifted to the higher-layer protocol.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Message Publishing and Persistence
|
||||
# Message Publishing
|
||||
|
||||
[TOC]
|
||||
|
||||
## Objective
|
||||
|
||||
To specify the mechanics and interfaces for publishing messages over Wormhole and how they are persisted.
|
||||
To specify the mechanics and interfaces for publishing messages over Wormhole.
|
||||
|
||||
## Background
|
||||
|
||||
|
|
@ -14,7 +14,6 @@ published needs to be defined clearly for chain endpoints to be built.
|
|||
## Goals
|
||||
|
||||
* Specify an interface for posting messages.
|
||||
* Define the concept of persisted and non-persisted messages.
|
||||
* Specify a fee model for message posting.
|
||||
|
||||
## Non-Goals
|
||||
|
|
@ -27,9 +26,6 @@ published needs to be defined clearly for chain endpoints to be built.
|
|||
The core Wormhole contracts on every chain will have a method for posting messages to Wormhole, which will emit an event
|
||||
that needs to be observable by guardians running a full node on a given chain.
|
||||
|
||||
The method will allow to specify whether the produced VAA shall be persisted onto Solana or just be circulated on the
|
||||
P2P network. Persisting messages will incur an increased fee vs. non-persisted attestations.
|
||||
|
||||
The fees will be payable in the respective chain's native currency. Fees can be
|
||||
claimed by the protocol and collected in a fee pool on Solana where they can be distributed according to protocol rules.
|
||||
|
||||
|
|
@ -56,19 +52,6 @@ When a message is posted, the emitter can specify for how many confirmations the
|
|||
attestation is produced. This allows latency sensitive applications to make sacrifices on safety while critical
|
||||
applications can sacrifice latency over safety. Chains with instant finality can omit the argument.
|
||||
|
||||
**Persistence:**
|
||||
|
||||
In case an emitter chooses to persist a message, the guardian software will publish it to the Solana blockchain where
|
||||
the full VAA including all signatures will be stored with rent exemption (i.e. forever). This is meant to allow a user
|
||||
to pick up a signed VAA from a browser with an unreliable connection, instead of having to listen to the P2P network or
|
||||
building a separate data availability layer.
|
||||
|
||||
The Solana Wormhole program will have a `postVAA` method which will verify and persist a VAA.
|
||||
|
||||
If no persistence is chosen, the signatures and VAA will only be constructable by nodes listening to the P2P network.
|
||||
This is meant for high-throughput data feeds where reliability is less important than cost-effectiveness, or use cases
|
||||
where a sophisticated setup on the receiving/consumer end takes care of data availability.
|
||||
|
||||
**Fees:**
|
||||
|
||||
In order to incentivize guardians and prevent spamming of the Wormhole network, publishing a message will require a fee
|
||||
|
|
@ -93,9 +76,7 @@ bridge tokens back to the chain where the governance and staking contracts are l
|
|||
|
||||
Proposed bridge interface:
|
||||
|
||||
`postMessage(bytes payload, bool persist, u8 confirmations)` - Publish a message to be attested by Wormhole.
|
||||
|
||||
`postVAA(VAA signed_vaa)` - Persist a VAA on chain (Solana only)
|
||||
`postMessage(bytes payload, u8 confirmations)` - Publish a message to be attested by Wormhole.
|
||||
|
||||
`setFees(VAA fee_payload)` - Update the fees using a `SetMessageFee` VAA
|
||||
|
||||
|
|
@ -117,8 +98,6 @@ Action uint16 = 3
|
|||
Chain uint16
|
||||
// Message fee in the native token
|
||||
Fee uint256
|
||||
// Persistent message fee in the native token
|
||||
FeePersistent uint256
|
||||
```
|
||||
|
||||
TransferFees:
|
||||
|
|
|
|||
Loading…
Reference in New Issue