Bridging delegator info from Symbiotic vaults to Kalypso contracts

Kalypso
1

TL;DR This post proposes a mechanism to transmit staking data from Symbiotic contracts on Ethereum to Kalypso contracts on Arbitrum.

Secure enclaves deployed on the Oyster network are used to bridge data between Ethereum and Arbitrum. Code to generate a signing key, read appropriate contracts on Ethereum/Arbitrum and sign results of the computation with the signing key are made public (which can be vetted by the community). Anyone can deploy an enclave by building an enclave image using this codebase. The enclave deployer can request an attestation for the enclave and get the generated signing key verified on-chain with the help of the attestation to prove that the corresponding private key is within an enclave built using the expected codebase. Transactions can then be constructed with the help of the enclave’s signed outputs to bridge data and/or results of computations run over it.

Trust assumptions

An Oyster-based bridge design comes with the following trust assumptions:

  • PCR values within the attestations provided by the TEE cannot be tampered without making the attestation invalid.
  • RPC endpoints used by the enclave for fetching data from Ethereum are secure. This assumption is to be removed in a future revision.
  • Incentives provided for data transfer between Ethereum and Arbitrum are sufficient for someone to take the initiative to transfer data.

Bridging VALSET data from Ethereum to Arbitrum

The Symbiotic contracts on Ethereum are the source of truth on which vault delegates how many tokens to which operator. This information is captured at events marked by a captureTimestamp on Ethereum and bridged to Arbitrum. Due to reasons mentioned in the tweet, it is assumed that there will be atleast two captureTimestamps per vault epoch.

The flow is as follows:

  1. The codebase to facilitate this process will be public and PCRs of associated enclave image will be added to a smart contract.

  2. An entity, could be anyone, referred to as Transmitter runs the enclave with the specified image (the Bridge enclave) which starts a server that accepts requests for creating the signed messages that can be used to transmit data on vault delegations towards different operators in the Kalypso network.

  3. The Transmitter verifies the signing key for the Bridge enclave on Arbitrum.

  4. The Transmitter then sends a request to the enclave server with the following inputs to generate the signed delegation data:

  5. API keys necessary for the RPC URLs that are predefined in the enclave to read chain data

  6. number of entries per signed message to enable splitting the data into multiple transactions

  7. (optional) Ethereum block number for which data has to be queried. If not specified, the latest block number is used.

  8. The signed delegation data might be divided into multiple transactions depending on the entries per transaction specified while sending the request. This is to enable splitting the delegation data contained in a snapshot from captureTimestamp into multiple transactions to avoid gasLimit issues.

  9. Signed delegation data provided from Bridge enclave server endpoint is as below:

    {
      noOfTxs: <integer>,
      captureTimestamp: <Timestamp>,
      signedData: [
            {
                  data: <stake data>,
                  signature: <signature on txIndex, noOfTxs, captureTimestamp, stake data>,
            },
            ……
      ]
}

  10. The Transmitter can use this information to submit transactions on a Symbiotic Delegation tracker contract on Arbitrum (described in the next section) to the following function:

    function submitSnapshot (
   uint256 txIndex,
   uint256 noOfTxs,
   uint256 captureTimestamp,
   bytes stakeData,
   bytes signature
)

  11. captureTimestamp should be SD time more than the captureTimestamp of the last complete snapshot submitted. The contract only uses complete snapshots. SD will be less than the epoch size of the Symbiotic vaults.

  12. A complete snapshot should include any slashing resolutions that were made on the stake chain between lastCaptureTimestamp and the current captureTimestamp. More details regarding the resolutions can be found in the slashing section.

  13. Any job created will use the latest snapshot data for delegation information and TC% of the fees towards the delegation from Symbiotic for the job will be provided to the Transmitter. TC is increased as the delay from the last snapshot increases. This ensures there are incentives for Transmitters to submit snapshots regularly.

Possible reasons as to why data might not be bridged even after 2*SD time:

  • all RPCs fail
  • there is a critical bug in the enclave’s codebase
  • the incentives are not good enough to relay this info to Arbitrum
  • Arbitrum stops working
1 Like