From a21b6f2e058702cd80acc8462788b0b62395a499 Mon Sep 17 00:00:00 2001 From: del-distributed <93844417+del-distributed@users.noreply.github.com> Date: Wed, 20 Nov 2024 22:00:08 +0400 Subject: [PATCH 1/4] Create UIP-0131.md --- UIPS/UIP-0131.md | 113 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 UIPS/UIP-0131.md diff --git a/UIPS/UIP-0131.md b/UIPS/UIP-0131.md new file mode 100644 index 0000000..c9a068b --- /dev/null +++ b/UIPS/UIP-0131.md @@ -0,0 +1,113 @@ +UIP-0130 Ministry: an Azimuth multibridge +========================================= + +Abstract +-------- + +Ministry enables Urbit's Azimuth PKI to operate across multiple blockchain platforms while maintaining Ethereum as its root of trust. The system introduces a secure bridging protocol that allows points to move between supported chains through galaxy-operated oracles. This proposal specifies both the general bridge architecture and a concrete first implementation supporting Coinbase's Base layer-2 rollup. + +Motivation +---------- + +The Urbit namespace currently exists solely on Ethereum. While Ethereum provides strong property rights guarantees, limiting Azimuth to a single chain restricts user optionality and increases operational costs. As the blockchain ecosystem evolves with new Layer 2s and alternative Layer 1s, there is value in making Urbit IDs portable while preserving both the security guarantees and property rights of the existing system. + +Moving points to more cost-effective chains reduces operational overhead for users. Integration with multiple blockchain ecosystems increases accessibility and enables future compatibility with specialized Urbit-specific chains or features available on select global consensus ledgers other than mainnet Ethereum. The proposal maintains security through a galaxy-based oracle system with robust economic incentives. + +Base provides an ideal first target for cross-chain support due to its Ethereum compatibility, established security model, and lower transaction costs. This implementation will validate the Ministry protocol architecture while delivering immediate practical benefits to the network. + +Specification +------------- + +### Bridge Architecture Overview + +Ministry implements a hierarchical bridge system with Ethereum serving as the senior chain. The Ministry Contract deployed on Ethereum acts as the root of trust. Each supported junior chain runs an Embassy Contract that maintains a local copy of relevant Azimuth state. + +Galaxies have the option to participate as oracles, validating cross-chain transfers by staking their own identities in the Ministry contract in exchange for fee revenues. The Senate governs the addition of new junior chains through a formal approval process, ensuring each chain meets security and technical requirements before its Embassy is deployed. + +### Transfer Protocol + +**Departure Process** + +1. Point owner initiates departure by submitting a request to the Ministry contract on Ethereum + +2. Ministry contract verifies eligibility and locks the point in the vault + +3. Galaxy oracles validate the departure ticket with their signatures off-chain + +4. Embassy contract on the junior chain verifies the signatures and creates the point + +5. Point becomes active on junior chain once minimum confirmation period is met + +**Return Process** + +1. Point owner initiates return process through the Embassy contract + +2. Embassy contract creates a return ticket containing destination address and merkle root of all junior chain activity + +3. Galaxy oracles validate the return ticket + +4. Ministry contract verifies oracle signatures + +5. Ministry contract releases point from the vault with specified state + +### State Management + +The Embassy contract maintains just the current state of points on its chain---their ownership addresses and proxy configurations. When a point arrives through the Ministry bridge, the Embassy registers only this essential current state data. + +For returns, the oracle-signed tickets need only contain the point's current ownership address and proxy configurations. This lightweight approach leverages the oracle trust model---since oracles stake their galaxies on providing accurate state transitions, maintaining historical state becomes unnecessary. The optimistic rollup's challenge mechanism relies on oracle signatures rather than state history verification. + +### Oracle Security Model + +Galaxies secure Ministry by staking their own identities in the contract. To operate as an oracle, a galaxy transfers itself to the Ministry contract as collateral. This ensures stake value inherently exceeds typical transfer values, as galaxy ownership is generally more valuable than subordinate points. While certain points may accumulate exceptional value through smart contract integrations or attached assets that could theoretically exceed a galaxy's worth, this economic reality does not impair the protocol's security model. + +The system enforces correct oracle behavior through social consensus and economic incentives. Invalid transfer tickets serve as evidence of misbehavior---any party can submit transaction references showing fraudulent ticket validation to the Ministry contract. These references locate the original transfer records on each chain. The reports support Senate governance decisions which may result in galaxy forfeiture. Multiple oracles provide redundancy in signature collection and transfer validation, ensuring the bridge remains operational even if some oracles are temporarily offline. + +The protocol implements rate limiting, mandatory cooldowns, and minimum confirmation periods to prevent timing attacks. A monitoring client watches both chains for fraudulent tickets and automates violation reporting. + +TODO: Specify signature thresholds, timeouts, rate limits, and violation report format. + +### Arvo Integration + +The introduction of multi-chain state requires significant changes to Urbit's PKI verification system. Currently, %jael maintains Azimuth state by synthesizing data from Ethereum and the naive rollup. The addition of Base requires extending this system to handle three distinct sources of truth. + +The %base-watcher agent extends %jael's PKI verification capabilities, monitoring Base chain activity and updating Azimuth state accordingly. While the Ministry bridge protocol handles transfer sequencing and validation through its vault mechanism and oracle system, %jael remains responsible for maintaining a consistent view of the PKI state. This includes tracking point locations across chains and handling state rollbacks that may occur before bridge transfers are finalized. + +In cases of rollbacks, %jael must ensure that its state synthesis algorithm appropriately handles the reversion without compromising the integrity of cross-chain point locations. This becomes particularly important when points are in transit between chains. + +TODO: Detail exact state synthesis algorithm for handling multi-chain state reconciliation. + +### Base Implementation + +Base's optimistic rollup architecture introduces specific timing requirements for the return path of the bridge protocol. While points can begin operating immediately upon arrival on Base, returns to Ethereum require waiting for Base's 7-day challenge period to expire. This ensures the Embassy contract state is final before the Ministry vault releases points back to Ethereum. + +Oracle validation windows adapt to Base's block confirmation schedule, requiring a minimum of 15 L2 blocks before accepting transfer tickets. The Embassy contract implements a local timeout mechanism to handle potential state synchronization issues between Base and Ethereum during return transfers. + +TODO: Specify exact block confirmation thresholds and timeout parameters. + +Rationale +--------- + +The design establishes Ethereum as the senior chain to preserve the existing security model while enabling point mobility. Using galaxies as oracles leverages the network's existing power structure and economic incentives rather than introducing external validators. Points maintain complete functionality across chains through comprehensive state transfer. + +Base's position as an Ethereum L2 makes it an ideal first implementation target. Its Ethereum compatibility simplifies transaction verification, while its established security model reduces implementation risks. The immediate benefit of lower transaction costs provides value to users while proving the architecture for future chain integrations. + +The ticket-based transfer mechanism creates explicit, verifiable state transitions with clear security checkpoints. This enables efficient validation while ensuring atomic transfers between chains, preventing any state where a point could exist simultaneously on multiple chains. + +Alternative approaches considered include trustless bridging (rejected due to complexity and security risks), multi-primary chains (which would complicate governance), lightweight state transfer (limiting functionality), and integration with official cross-chain bridges. While integration with established bridge providers merits further exploration, the current design optimizes for sovereignty and operational consistency while maintaining upgradeability. + +While Ministry establishes Ethereum as the current senior chain, this architecture does not presume Ethereum's permanent primacy. The design anticipates an increasingly multichain future for Azimuth, with evolutionary paths that maintain galaxy-based governance through the Galactic Senate while allowing technical implementation to adapt through the Core Guild. This flexibility enables the system to evolve alongside blockchain technology while preserving Urbit's governance model. + +Backwards Compatibility +----------------------- + +The Ministry bridge system maintains full compatibility with existing Azimuth functionality. Points remaining on Ethereum continue operating without modification, while the bridge introduces new capabilities without affecting existing operations. + +Reference Implementation +------------------------ + +The reference implementation led by ~rolryx will focus on core contract development, oracle client implementation, Azimuth integration, and test network deployment. Initial development prioritizes security and reliability over feature completeness. The modular design enables iterative enhancement of bridge capabilities as the system proves stable in production use. + +Copyright +--------- + +Copyright and related rights waived via [CC0](https://github.com/urbit/UIPs/blob/LICENSE.md). From 012951c207dbd3427f6ca09347ec49583c157371 Mon Sep 17 00:00:00 2001 From: del-distributed <93844417+del-distributed@users.noreply.github.com> Date: Wed, 20 Nov 2024 22:05:10 +0400 Subject: [PATCH 2/4] Update UIP-0131.md add header --- UIPS/UIP-0131.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/UIPS/UIP-0131.md b/UIPS/UIP-0131.md index c9a068b..edf7b30 100644 --- a/UIPS/UIP-0131.md +++ b/UIPS/UIP-0131.md @@ -1,4 +1,15 @@ -UIP-0130 Ministry: an Azimuth multibridge +--- +uip: "0131" +title: "Ministry" +description: An Azimuth Multibridge +author: ~master-malwyl, ~rolryx, ~sarlev-sarsen +status: Draft +type: Standards Track +category: Kernel, PKI +created: ~2024.11.20 +--- + +UIP-0131 Ministry: an Azimuth multibridge ========================================= Abstract From 3b53503715c76d15502f51e470e125f88242cb58 Mon Sep 17 00:00:00 2001 From: del-distributed <93844417+del-distributed@users.noreply.github.com> Date: Wed, 20 Nov 2024 22:06:09 +0400 Subject: [PATCH 3/4] Update UIP-0131.md change category --- UIPS/UIP-0131.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UIPS/UIP-0131.md b/UIPS/UIP-0131.md index edf7b30..72dd609 100644 --- a/UIPS/UIP-0131.md +++ b/UIPS/UIP-0131.md @@ -5,7 +5,7 @@ description: An Azimuth Multibridge author: ~master-malwyl, ~rolryx, ~sarlev-sarsen status: Draft type: Standards Track -category: Kernel, PKI +category: PKI created: ~2024.11.20 --- From 099a581943ac80e8042f7af2d1c7d933a8311faf Mon Sep 17 00:00:00 2001 From: del-distributed <93844417+del-distributed@users.noreply.github.com> Date: Wed, 20 Nov 2024 22:06:54 +0400 Subject: [PATCH 4/4] Update UIP-0131.md remove header --- UIPS/UIP-0131.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/UIPS/UIP-0131.md b/UIPS/UIP-0131.md index 72dd609..7b41a73 100644 --- a/UIPS/UIP-0131.md +++ b/UIPS/UIP-0131.md @@ -9,9 +9,6 @@ category: PKI created: ~2024.11.20 --- -UIP-0131 Ministry: an Azimuth multibridge -========================================= - Abstract --------