| uip | 0131 |
|---|---|
| title | Ministry |
| description | An Azimuth Multibridge |
| author | ~master-malwyl, ~rolryx, ~sarlev-sarsen |
| status | Draft |
| type | Standards Track |
| category | PKI |
| created | ~2024.11.20 |
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.
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 validator system.
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.
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 may choose to serve as validators, authenticating cross-chain transfers as an optional governance activity. Not all galaxy holders will operate validator infrastructure, but a sufficient number must participate to ensure system security. The Senate governs the addition of new junior chains, ensuring each meets security and technical requirements before its Embassy is deployed.
Ministry implements a dual-key security model that leverages Azimuth's existing infrastructure:
- Hot keys: Validator management proxies serve as hot keys for routine operations like signing transfer confirmations. These keys can remain on internet-connected servers for daily operations.
- Cold keys: Validator ownership addresses function as cold keys, used only for critical security operations like unlocking a frozen bridge. These keys should be kept in secure cold storage.
This separation of concerns follows industry best practices by keeping frequently used operational keys separate from high-security ownership keys. Azimuth's existing management proxy system provides a perfect foundation for this security model.
Departure Process
To move a point to a junior chain, the owner transfers it to the Ministry contract with the target destination as a parameter. This automatically generates a departure record on Ethereum. Validators monitor the Ministry contract and submit confirmations on the junior chain's Embassy contract. When enough validators have confirmed the transfer, the Embassy contract creates the point. The point becomes active on the junior chain once the minimum confirmation period is met.
Return Process
For returns, the point owner initiates the process through the Embassy contract. The Embassy creates a return record with the destination address and the point's current state. Validators monitor the Embassy contract and submit confirmations to the Ministry contract on Ethereum. When enough validators have confirmed the return, and after the appropriate waiting period, the Ministry contract releases the point to the specified address with the updated state data.
The Ministry bridge must handle various state scenarios depending on a point's history across chains.
For points departing Ethereum, validators relay the point's current ownership and proxy configurations to the junior chain's Embassy contract, which initializes the point with this data.
For points returning to Ethereum, validators relay the current state from the junior chain. If the point previously existed on Ethereum, the Ministry contract updates its state accordingly.
For points spawned on a junior chain that have never existed on Ethereum, validators must provide complete initialization data when the point first arrives on Ethereum. This includes information about the point's lineage (which parent spawned it) and its current configuration.
The Ministry protocol provides mechanisms to resolve conflicts in the rare case of discrepancies between validator reports.
The Ministry system organizes validators into epochs, with clear procedures for updating the validator set. Changes to the validator set require approval through the Senate's governance process, followed by a dispute period before finalization.
New validator set epochs can only begin after the current epoch completes its minimum duration. This ensures orderly transitions between validator groups and prevents rapid changes that could compromise security.
The Ministry contract maintains a registry of active galaxy validators with on-chain governance mechanisms to manage the validator set. Galaxies can opt in to validator duties through a registration process, and may withdraw from service following an orderly transition procedure. The Senate retains authority to remove validators for improper behavior.
Validators secure Ministry by validating cross-chain transfers. Their reputation and continued role in network governance incentivizes honest behavior. While validator service is optional, participating galaxies commit to maintaining reliable operations and following security protocols.
The Ministry bridge includes multiple layers of security protections. All critical operations include a dispute period, providing time for intervention if validators detect suspicious activity. This includes validator set updates, parameter changes, and transfer operations.
To prevent attacks and ensure security, the system enforces mandatory waiting periods sized appropriately to the underlying chains' finality guarantees. For the Base implementation, this means accounting for its 7-day challenge period for returns to Ethereum.
The emergency response system allows any validator to trigger a lock using their management proxy (hot key) if they detect potentially fraudulent activity. Once locked, bridge operations are suspended until a quorum of validators use their ownership keys (cold keys) to authorize unlocking. This asymmetric design makes the bridge easy to secure in an emergency but difficult to unlock without proper authorization.
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's optimistic rollup architecture introduces specific timing requirements for bridge operations. While points can begin operating immediately upon arrival on Base, returns to Ethereum must wait for Base's 7-day challenge period to expire.
Validator consensus windows adapt to Base's block confirmation schedule, requiring a minimum threshold of L2 blocks before accepting transfer tickets. The Embassy contract on Base includes timeout mechanisms to handle potential state synchronization issues between chains.
The Ministry design establishes Ethereum as the senior chain to preserve Azimuth's existing security model while enabling point mobility. Using participating galaxies as validators leverages the network's existing governance structure rather than introducing external validators, while respecting that not all galaxy holders will choose to operate validation infrastructure.
The security model leverages Azimuth's existing management proxy system as hot keys for routine operations while reserving critical functions for ownership keys (cold keys). By separating daily activities from security-critical functions, the system minimizes risk while maintaining operational efficiency.
The explicit dispute periods for all sensitive operations create time buffers during which validators can intervene if they detect problems. This deliberate approach to critical functions prioritizes security over speed for important state transitions.
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 bridge architecture for future chain integrations.
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, maintaining Senate governance while allowing technical implementation to adapt.
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.
Copyright and related rights waived via CC0.