Add new chain docs

docs/astro.config.ts

@@ -191,16 +191,56 @@ export default defineConfig({
             },
             {
               label: "Architecture",
-              autogenerate: {
-                directory: "/architecture"
-              }
+              items: [
+                {
+                  label: "CometBLS",
+                  link: "/architecture/cometbls"
+                },
+                {
+                  label: "Galois",
+                  link: "/architecture/galois"
+                },
+                {
+                  label: "Voyager",
+                  items: [
+                    { label: "Overview", link: "/architecture/voyager/overview" },
+                    { label: "Concepts", link: "/architecture/voyager/concepts" }
+                  ]
+                }
+              ]
             },
             {
               label: "Concepts",
               autogenerate: {
                 directory: "/concepts"
               }
             },
+            {
+              label: "Connect",
+              items: [
+                {
+                  label: "New Chain",
+                  items: [
+                    {
+                      label: "Overview",
+                      link: "/connect/new-chain/overview"
+                    },
+                    {
+                      label: "EVM",
+                      link: "/connect/new-chain/evm"
+                    },
+                    {
+                      label: "CosmWasm",
+                      link: "/connect/new-chain/cosmwasm"
+                    },
+                    {
+                      label: "Move",
+                      link: "/connect/new-chain/move"
+                    }
+                  ]
+                }
+              ]
+            },
             {
               label: "Infrastructure",
               items: [

docs/src/content/docs/architecture/voyager/concepts.mdx

@@ -0,0 +1,70 @@
+---
+title: "Voyager Concepts"
+---
+
+![voyager ibc architecture](./ibc-architecture.svg)
+
+## Modules and Plugins
+
+All functionality in voyager is provided by modules and plugins. Modules provide various forms of read-only data, such as the latest height of a chain or a state proof. Plugins, on the other hand, directly interact with the queue - every plugin has their own [topic queue](https://github.com/unionlabs/union/blob/main/lib/voyager-vm/README.md) with it's plugin name as the topic, along with an interest filter that can pull messages into this queue. Plugins also define their own internal message types that they can use to pass data around between calls to their internal queue (or even between other plugins).
+
+## Types
+
+### IBC Specification
+
+An IBC specification defines the semantics of a light client based bridging protocol. A specification must have the following properties:
+
+- some notion of a "light client update"
+- a store specification, where client and consensus states are stored (among any other states required by the IBC specification)
+- this store is required to be provable (i.e. the host environment must have some form of "proof" for it's storage, most likely merkleized)
+
+Everything else is an implementation detail of the ibc specification.
+
+### Chain
+
+A chain is defined by a few basic properties:
+
+- produces blocks with an incrementing height (sometimes also referred to as "block number" or "slot")
+- a consensus with some notion of finality, where blocks older than the latest finalized height will never reorg and are considered finalized
+- a storage layer with provable state
+- one or more IBC interfaces
+
+### Consensus
+
+A chain's consensus defines the client and consensus state types stored in the clients that verify this consensus.
+
+#### Examples
+
+- cometbls
+- tendermint
+- ethereum
+
+### IBC Interface
+
+An IBC interface defines the entrypoints of an IBC specification implementation on a chain. A chain can potentially have many different IBC interfaces (for example, `ibc-go` native clients vs. `08-wasm` clients), and a consensus can be verified by the same client specification on different IBC interfaces.
+
+#### Examples
+
+- ibc-go-v8/08-wasm
+- ibc-solidity
+- ibc-cosmwasm
+
+### Client
+
+Clients are the mechanism used to verify a counterparty consensus. Clients are defined by 4 properties:
+
+- compatible with an IBC specification
+- on an IBC interface
+- for a specific consensus mechanism
+- which is verified via a consensus verification specification
+
+#### Examples
+
+| IBC interface     | consensus  | verifier         |
+|-------------------|------------|------------------|
+| ibc-go-v8/08-wasm | cometbls   | cometbls-groth16 |
+| ibc-go-v8/08-wasm | cometbls   | 11-cometbls      |
+| ibc-go-v8/native  | cometbls   | cometbls-groth16 |
+| ibc-solidity      | cometbls   | cometbls-groth16 |
+| ibc-go-v8/native  | tendermint | 07-tendermint    |
+| ibc-go-v8/08-wasm | tendermint | 07-tendermint    |

docs/src/content/docs/architecture/voyager/overview.mdx

@@ -0,0 +1,60 @@
+---
+title: "Voyager"
+---
+
+
+import Mermaid from "#/components/Mermaid.astro";
+
+Relaying is hard. There are several key properties to a reliable relayer, the most important of
+which being:
+
+- **Speed.** IBC Relaying is a race to the bottom, with many relayers fighting to be the first to
+  submit a packet, often times submitting a packet that ends up being frontrun.
+- **Data Integrity.** There's no use being the first to submit a packet if the packet is submitted
+  incorrectly, and a good relayer will never drop packets. The latter is especially important for
+  ordered channels, as a channel will be closed if a packet on it times out.
+- **Quick Startup Times.** RPCs are unreliable, and it's incredibly difficult to build around every
+  possible failure case - especially when connecting to multiple different chains. Even with proper
+  error handling and retry logic, in the event of a crash, startup time should be miniscule (see:
+  https://github.com/clemensgg/xion-relayer-postmortem)
+
+Voyager takes a novel approach to solving these problems. Internally, everything is modeled as a
+finite state machine, ([`voyager-vm`](/lib/voyager-vm/README.md)), which is stored in postgres to ensure transactional integrity ([`pg-queue`](/lib/pg-queue/README.md)). Every chain
+query, transaction submission, and even the data itself is represented as a state within the queue.
+This design solves two of the properties mentioned above out of the box: **Data Integrity** and
+**Quick Startup Times**. Since no state is stored in Voyager itself, it is able to crash and restart
+exactly where it left off, making startup times lightning fast; and since every message is processed
+within a postgres transaction, we are guaranteed that the data we're working with is correct
+(barring a bug in the business logic, of course). The final property, **Speed**, is also solved
+by this design - since each message fully encapsulates all the state it needs to operate, multiple
+messages can safely be executed in parallel. This means, for instance, that while one worker is
+fetching events from a block, another could be submitting a light client update, and another could
+be generating a state proof, and so on.
+
+For more information on voyager's architecture, see [CONCEPTS.md](/voyager/CONCEPTS.md)
+
+## Light Clients
+
+Voyager implements the relaying logic for several light client protocols. Some of these are existing
+specifications, such as tendermint and ethereum, but most are custom implementations for chains
+Union has connected to IBC.
+
+Many of these custom light clients build off of our existing light client infrastructure for
+ethereum and tendermint, with additional logic specific to the protocol's finality.
+
+### L2 Clients
+
+Voyager supports several Ethereum L2s, which are implemented as conditional light clients (TODO:
+link to our doc on conditional clients)
+
+The settlement condition and update logic is different for each L2, but the basic principles are
+the same:
+
+- Verify the account root of the L2 rollup contract on the L1
+- Verify the L2 state is stored in the L2 rollup contract
+- Verify the IBC account root against the rollup root
+
+The consensus height of L2 clients is the consensus height of the L1 (which in the case of Ethereum
+L2s is the height of the beacon chain), and L2 clients are can only be updated to heights that
+the L1 client it tracks has a consensus state for. As such, the finality time for L2s is the L2
+settlement period + L1 finality time.

docs/src/content/docs/connect/new-chain.mdx → docs/src/content/docs/connect/new-chain/cosmwasm.mdx

@@ -1,28 +1,26 @@
 ---
-title: "Connect a new Chain"
+title: "Connect a CosmWasm Chain"
 ---
 
 import { Tabs, TabItem, FileTree, Steps } from '@astrojs/starlight/components'
 
-If your chain is not yet [connected to Union](/protocol/chains/overview/), then you can permissionlessly add support. Union supports L1s, L2s, L3s, and Rollups. The steps to connect are simple:
+Connecting a new CosmWasm chain is easy and can be done in four simple steps documented here:
 
 <Steps>
-1. Upload Union contracts
-2. Configure a relayer
-3. Open the connection
-4. Send assets and data
+1. Upload `ibc-core` and `light-client` contracts.
+2. Configure the [Voyager](/architecture/voyager) relayer.
+3. Open the connection.
+4. Send assets and data.
 </Steps>
 
-## Upload Union contracts
+## Upload IBC Core and Light Clients
 
 You'll need to upload two contracts:
 
 - [union-ibc](https://github.com/unionlabs/union/tree/main/cosmwasm/union-ibc/core): Union's modular IBC stack.
 - [cometbls-light-client](https://github.com/unionlabs/union/tree/main/cosmwasm/union-ibc/light-clients/cometbls): Light-client tracking [CometBLS](/architecture/cometbls) consensus.
 
 
-### Cosmos
-
 To upload [CosmWasm](https://cosmwasm.com/) contracts to your Cosmos chain, you need your chain's binary. We'll use `starsd` in this example. 
 
 ```bash
@@ -83,6 +81,54 @@ mkdir ./starsd-home
    ```bash
    ./starsd tx wasm execute stars1s0x3yq0pmltxq56f4yppgmd02ret3uj5k9ftj6ug9c7lc379sw7qv396zm '{"register_client":{"client_type":"cometbls","client_address":"stars16khctrjjnm5nn5503hhqlcu7h4pngzpzc5g3d4ej25pz47eqsnjqdctmt7"}}' --home ./starsd-home --node https://rpc.elgafar-1.stargaze.chain.kitchen --chain-id elgafar-1 --from cor-systems --gas auto  --gas-adjustment 1.4 --gas-prices 1ustars -y
    ```
+10. TODO: Show registration of State Lens LCs
 </Steps>
 
+### Short version (will merge with above later)
+
+```
+- get contract binaries
+  - nix build github:unionlabs/union#ibc-union
+  - nix build github:unionlabs/union#cometbls-light-client
+  - outputs will be in ./result/
+
+- upload contracts to chain
+  - be sure to note the code ids for the uploaded code
+
+- instantiate ibc-union
+  - $NODED tx wasm instantiate IBC_UNION_CODE_ID '{}'
+    - note the contract address of the instantiated contract
+
+- instantiate cometbls-light-client
+  - $NODED tx wasm instantiate COMETBLS_LIGHT_CLIENT_CODE_ID '{"ibc_host":"IBC_UNION_CONTRACT_ADDRESS"}'
+    - note the contract address of the instantiated contract
+
+- register cometbls-light-client
+  - $NODED tx wasm execute IBC_UNION_CONTRACT_ADDRESS '{"register_client":{"client_type":"cometbls","client_address":"COMETBLS_LIGHT_CLIENT_CONTRACT_ADDRESS"}}'
+```
+
+
+## Configure Voyager
+
+<Steps>
+1. get voyager binary
+
+   ```bash
+     nix build github:unionlabs/union#voyager
+   ```
+   ```bash
+     nix build github:unionlabs/union#voyager-modules-dev
+   ```
+2. tweak config
+
+   [voyager config](./voyager-example-config.jsonc)
+
+</Steps>
+
+
+
+## Open the Connection
+
+TODO
+
 

docs/src/content/docs/connect/new-chain/evm.mdx

@@ -0,0 +1,59 @@
+---
+title: "Connect an EVM Chain"
+---
+
+import { Tabs, LinkCard, TabItem, FileTree, Steps } from '@astrojs/starlight/components'
+
+Connecting a new CosmWasm chain is easy and can be done in four simple steps documented here:
+
+<Steps>
+1. Upload `ibc-core` and `light-client` contracts.
+2. Configure the [Voyager](/architecture/voyager) relayer.
+3. Open the connection.
+4. Send assets and data.
+</Steps>
+
+## Upload IBC Core and Light Clients
+
+Deployment of the Union EVM stack is fully automated. You can add a chain definition, and Union will generate deployment scripts for you. 
+
+<Steps>
+1. Clone `unionlabs/union`:
+
+   ```bash
+   git clone [email protected]:unionlabs/union
+   ```
+
+2. Add your chains configuration to [`evm/evm.nix`](https://github.com/unionlabs/union/blob/a408b8344d6c90791825e837d2be350809213695/evm/evm.nix#L214C9-L219C10). For example:
+
+   ```nix
+   {
+     network = "holesky";
+     rpc-url = "https://1rpc.io/holesky";
+     private-key = ''"$1"'';
+     extra-args = ''--verify --verifier etherscan --etherscan-api-key "$2"'';
+   }
+   ```
+
+3. Use the gernated reproducible deployment script.
+
+   ```bash
+   nix run github:unionlabs/union#eth-deploy-$NETWORK-full
+   ```
+   for example, if your network is `"holesky"` above, it will be:
+
+   ```bash
+   nix run github:unionlabs/union#eth-deploy-holesky-full $EVM_PRIVKEY $ETHERSCAN_API_KEY
+   ```
+
+   Providing an Etherscan API key is optional, but highly recommened as it will verify the uploaded contracts for you.
+</Steps>
+
+
+## Configure Voyager
+
+TODO
+
+## Open the Connection
+
+TODO

docs/src/content/docs/connect/new-chain/move.mdx

@@ -0,0 +1,7 @@
+---
+title: "Connect a Move Chain"
+---
+
+TODO
+
+