diff --git a/src/components/table.jsx b/src/components/table.jsx new file mode 100644 index 000000000..21354f6c8 --- /dev/null +++ b/src/components/table.jsx @@ -0,0 +1,233 @@ +import React from 'react'; + +const Table = () => { + const headerBackgroundColor = '#808080'; + + const data = [ + { + category: "Amplifier Contracts", + component: "Chain-specific Amplifier contracts: Gateway, Verifier, Prover", + description: (<> +
There are three contracts you need to adapt: the Verifier Contract, the Gateway Contract, and the Multisig Prover Contract.
+
+
It is up to the integrator to determine how to best utilize the reference contracts, whether that may be by using the reference contracts we expose as is, maintaining a fork, or something else.
+ ), + links: ( + <> +
TBD - to eventual replace with an INTEGRATION.md file that lives in the axelar-amplifier repo
+
+ Multisig Prover,{" "} + Gateway,{" "} + Voting Verifier + ), + }, + { + category: "Amplifier Contracts", + component: "Internal Contracts on Axelar: Coordinator, Multisig, Router, Service Registry, Rewards, Governance", + description: (<> +
These contracts are global to the protocol and provide a stable API to integrators. Integrators should not develop or fork any of the protocol contracts.
+
+
If there are any changes that need to be made to these contracts (e.g. such as the addition of a new signature scheme that needs to be added to the multisig contract, or message ID validation in the router contract, for example), integrators should expect to coordinate with the Interop Labs team to incorporate those changes.
+ ), + links: ( + <> +
TBD - to eventual replace with an INTEGRATION.md file that lives in the axelar-amplifier repo
+
+ Coordinator,{" "} + Multisig,{" "} + Rewards,{" "} + Router,{" "} + Service Registry,{" "} + Rewards + ), + }, + { + category: "Amplifier Contracts", + component: "ampd", + description: (<> +
Ampd is the off-chain daemon responsible for voting and signing within the amplifier protocol. The daemon listens to the Axelar blockchain for specific events, connects to external blockchains via JSON-RPC, and uses tofnd for signing transactions and batches of messages
+
+
If a chain does not conform to standard EVM compatibility, a pull request should be made to the Amplifier repo with a new module for that chain. In the future, Interop Labs will expose a plugin architecture to replace the current mechanism - details TBD.
+ ), + links: ampd readme + }, + { + category: "External Chain Contracts", + component: "Source Chain Gateway Contract", + description: "A smart contract implementing the Cross-Chain Gateway Protocol. For EVM chains, the EVM Gateway can be reused.", + links: ( + <> + Cross-Chain Gateway Protocol specifications,{" "} + Amplifier Gateway Integration + + ), + }, + { + category: "External Chain Contracts", + component: "Governance Contract", + description: "A source chain contract to receive governance-related messages from Axelar, such as updates to your gateway.", + links: ( + <> + Sample governance contracts + + ), + }, + { + category: "External Chain Contracts", + component: "Gas Service Contract", + description: "TBD", + links: "TBD" + }, + { + category: "External Chain Contracts", + component: "ITS", + description: "ITS", + links: "TBD" + }, + { + category: "External Chain Contracts", + component: "Squid", + description: "Squid", + links: ( + <> + Squid Router contract requirements + ) + }, + { + category: "Relaying", + component: "Relayer API components (sentinel, listener, relayer)", + description: "Relayer API components (sentinel, listener, relayer)", + links: (<> + Automated relaying architecture + TBD - Example utilization + ) + }, + { + category: "Relaying", + component: "GMP data collection", + description: "By leveraging the Relayer API above, GMP events for all transactions are automatically sent to our indexers. More information on the schema of the GMP data and all event types are listed here.", + links: "TBD - need to flesh out docs on the schema that is produced here" + }, + { + category: "Relaying", + component: "Gas reconciliation and tracking", + description: "TBD - but this section should go over the accounting of gas payments by users, refunds for overpayments issues by the Relayer API, and the settlement mechanism of discrepancies with accounting", + links: null + }, + { + category: "Verifiers", + component: "Instantiate verifier set to support the Amplifier chain (fund rewards, etc)", + description: "[TBU] Today, there is a global set of 30 verifiers ready to support a new chain connection. A new connection will need to coordiate with the verifier set to fund rewards pools and have them initiate chain connections", + links: "TBD" + }, + { + category: "Additional Services", + component: "Axelarscan APIs (GMP fee estimation, GMP transaction queries)", + description: "For all supported chains on Axelar, Interop Labs exposes a number of query APIs, such as gas fee estimations, GMP transaction statuses, etc. With some input from you, your chain can be supported as well.", + links: ( + <> + Axelarscan API documentation,{" "} +

+
TBD - to eventually replace with an INTEGRATION.md file that walk through CLI process in this repo for adding a chain. This will primarily include basic chain properties, gas assumptions, deployed contract addresses
+ Sample chain config + + ) + }, + { + category: "Additional Services", + component: "Axelarscan UI (static chain info, verifier performance, GMP data)", + description: "Once the above config is approved for the Axelarscan APIs, the new chain should appear on Axelarscan UI out of the box!" + }, + { + category: "Additional Services", + component: "AxelarJS SDK Support", + description: "The AxelarJS SDK is a Javascript wrapper for several helpful utility functions to the Axelar network, including transaction recovery, querying fee estimations, etc. Interop Labs will develop a plugin for you to adapt your chain into these SDKs, expected to be available in Q4", + links: "TBD" + }, + { + category: "Operations & Monitoring", + component: "Standardized deployment scripts for CICD", + description: "Standardized deployment scripts for CICD", + links: "TBD" + }, + { + category: "Operations & Monitoring", + component: "Monitoring for smart contracts (rate limits, large transfers, rotations, etc)", + description: "Monitoring for smart contracts (rate limits, large transfers, rotations, etc)", + links: "TBD" + }, + { + category: "Operations & Monitoring", + component: "Monitoring for relaying robustness (missed transactions, recovery, etc)", + description: "Monitoring for relaying robustness (missed transactions, recovery, etc)", + links: "TBD" + }, + { + category: "Operations & Monitoring", + component: "(If using Axelar governance) coordinated governance for upgrades", + description: "(If using Axelar governance) coordinated governance for upgrades", + links: "TBD" + }, + { + category: "Operations & Monitoring", + component: "Update global chains config", + description: "Update global chains config", + links: "TBD" + }, + { + category: "Testing", + component: "Deployment scripts for chains to play well with e2e testing", + description: "Deployment scripts for chains to play well with e2e testing", + links: "TBD" + }, + { + category: "Testing", + component: "GMP tests to/from chain", + description: "GMP tests to/from chain", + links: "TBD" + } + ]; + + const renderRows = (data) => { + let lastCategory = null; + + return data.map((row, index) => { + let rowSpan = 1; + + if (row.category !== lastCategory) { + // Count how many rows have the same category + const sameCategoryRows = data.filter(item => item.category === row.category); + rowSpan = sameCategoryRows.length; + lastCategory = row.category; + } + + return ( + + {/* Only display the category in the first row with rowspan */} + {index === 0 || data[index - 1].category !== row.category ? ( + {row.category} + ) : null} + {row.component} + {row.description} + {row.links} + + ); + }); + }; + + return ( + + + + + + + + + + {renderRows(data)} +
CategoryComponentDescriptionLinks
+ ); +}; + +export default Table; diff --git a/src/content/docs/dev/amplifier/chain-integration/introduction.mdx b/src/content/docs/dev/amplifier/chain-integration/introduction.mdx index ade948714..d17c0d0bb 100644 --- a/src/content/docs/dev/amplifier/chain-integration/introduction.mdx +++ b/src/content/docs/dev/amplifier/chain-integration/introduction.mdx @@ -1,12 +1,25 @@ # Introduction to Chain Integration import { Callout } from "/src/components/callout" +import Table from "/src/components/table" The Axelar Virtual Machine (AVM) and Amplifier are currently under active development, so these instructions are likely to change. Please check back frequently for updates. -## Integration Architecture +There are several components to build to integrate a chain into Amplifier. The main components to make the chain operational include: +1. building Amplifier contracts +2. building gateway contracts on the connected chain +3. building a relayer to send messages to/from the connected chain +4. establishing a verifier set +5. Additionally, Interop Labs exposes a set of API/SDK services that, with some configuration, will support your chain as well + +A table of the major components are as follows: + + + + +## [TBD - consider moving to component-specific repos] Integration Architecture To connect your chain to the Axelar network via the Interchain Amplifier, you'll need to build or instantiate 4 smart contracts and 1 relayer service. - **Source Chain Gateway Contract** @@ -36,7 +49,7 @@ To connect your chain to the Axelar network via the Interchain Amplifier, you'll The [chain integration tutorial](/dev/amplifier/chain-integration/integrate-a-chain) will guide you through this process within the current Amplifier DevNet. Contract deployment on Testnet or Mainnet will require governance proposal. -## Integration Process +## [TBD - consider moving to component-specific repos] Integration Process Most integrators will follow the following process: 1. Learn & Understand Amplifier