Closed vgeddes closed 2 months ago
Oak security will soon (in the next few days), issue an audit report covering the latest changes to our codebase, as well as the runtime configuration.
could be possible to know the scope of the audit? specially which parts are the latest changes and why those were selected instead of a retest of previous audit scope which had findings.
could be possible to know the scope of the audit? specially which parts are the latest changes and why those were selected instead of a retest of previous audit scope which had findings.
This is the scope that we asked the auditors to cover:
Component: Substrate pallets and support crates
Repository: https://github.com/paritytech/polkadot-sdk.git
Commit: b42d1968d93e1f22d402aa831a28ad1545b3d71a
Paths:
* bridges/snowbridge/pallets
* bridges/snowbridge/primitives
* bridges/snowbridge/runtime/runtime-common
Scope: Changes since last audit of repository https://github.com/snowfork/snowbridge at revision 1e27bce2c34989fd48f77d0ac8b6909ff09793c7
Component: Parachain Runtimes
Repository: https://github.com/polkadot-fellows/runtimes.git
Commit: 7a523172a2c63eab94356ef0bfb2e4c375efc724
Paths:
* system-parachains/asset-hubs/asset-hub-kusama/
* system-parachains/asset-hubs/asset-hub-polkadot/
* system-parachains/bridge-hubs/bridge-hub-kusama/
* system-parachains/bridge-hubs/bridge-hub-polkadot/
Scope:
* AssetHub: XCM configuration for messaging with snowbridge pallets on BridgeHub
* BridgeHub:
* Runtime configuration for all snowbridge pallets
* XCM configuration for snowbridge pallets
Component: Ethereum Contracts
Repository: https://github.com/Snowfork/snowbridge.git
Commit: 10875e90cd1cf35cb039a382586f767ba19a8b9e
Path: contracts/
Scope: Changes since last audit on repository https://github.com/snowfork/snowbridge at revision 1e27bce2c34989fd48f77d0ac8b6909ff09793c7
We acknowledge the auditors had certain findings, cases where bridge messages could fail to be processed. However these would always be a result of user error, such as supplying invalid fee parameters.
The auditors included our feedback in the previous audit report, where we state that a UX layer would be responsible for mediating access to the bridge, ensuring that low-level bridging APIs are called with the correct parameters.
There are also features on the XCM roadmap which will greatly help with error recovery, including Custom Asset Claimer and fee handling in general. However these are not available today.
The whitelisting referendum has executed successfully. Thanks for the approving fellowship folks!
Please direct any further comments about the initialization of Snowbridge here: https://polkadot.polkassembly.io/referenda/680
For the BridgeHub<->Ethereum bridge to operate, we need to perform a few initialization routines, that are all baked into a single batched preimage.
Fellowship referendum
Since I am not currently a fellowship member, I would like to request that the fellowship initiate this referendum on my behalf:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-collectives-rpc.polkadot.io#/extrinsics/decode/0x3d003e0202d10f283251f659dcc2605aa5a256163e97e114726ff448364a4aa3a9875344f435000000010a000000
A preimage has already been created on the collectives chain using this call:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-collectives-rpc.polkadot.io#/extrinsics/decode/0x2b00d41f0003010003082f0000060342090a75216f881700ea27d4347656f87e303402cfc98ce2f492b4d0d4751dcd51fca0bdcd213a73f2
The full initialization preimage can be viewed at: https://polkadot.polkassembly.io/referenda/680
Details
AssetHub
Enable AssetHub->BridgeHub->Ethereum bridging operations by setting the following runtime storage field:
BridgeHubEthereumBaseFee: 11.4565682000 DOT
BridgeHub
Set address for Snowbridge Gateway contract
The gateway is the bridging endpoint on Ethereum
EthereumGatewayAddress: 0x27ca963C279c93801941e1eB8799c23f407d68e7
NOTE: The deployment of the Gateway is being performed over two stages, to reduce costs and eliminate potential for breakage which could take months to fix.
Initially, a Gateway proxy contract has been deployed, which delegates all behavior to a bare Shell contract. This shell contract has no capability other than being upgraded by a trusted operator (which is me).
Finally, we will upgrade the shell to the full trustless and decentralized implementation contract, that only be upgraded via Polkadot OpenGov through BEEFY consensus. This will occur when we are reasonably certain that
This phased deployment also reduces costs for us considerably, while we wait for our bridge to be activated. Since it would cost us roughly $23000 per month in relaying consensus messages to our BEEFY client.
Set pricing parameters
Bridging fees for user messages (ie token transfers) are currently calculated using static values that can only be updated via governance.
Some background information:
The pricing parameters we have chosen have considerable buffer to ensure that the AssetHub sovereign accounts, when manually rebalanced, will always be positive.
Our team will fund these sovereign accounts for the initial month of operation.
NOTE: We are going to be improving the fee model substantially as a priority in upcoming releases. These improvements will include:
BaseFeePerGas
field in execution chain headers.Set Gateway operating mode
Enables Ethereum->AssetHub ERC20 token transfers.
Set initial checkpoint for the Beacon light client
This operation activates our beacon light client and allows it to follow the progress of the beacon chain.
The checkpoint has been derived from this beacon chain slot: https://beaconscan.com/slot/8870560
Testing
The initialization preimage has been tested in a simulated chopsticks environment that:
The preimage executed successfully, and furthermore:
Preimage generation
The initialization preimage was generated using this command implemented by a governance tool we developed:
Sequencing
The initialization preimage should only execute after the 1.2.0 runtime upgrade
Audits
Oak security will soon (in the next few days), issue an audit report covering the latest changes to our codebase, as well as the runtime configuration.
They have completed two previous audits available at: https://github.com/oak-security/audit-reports/tree/main/Snowbridge
Resources