UIP-0131: Ministry, an Azimuth Multibridge #69
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,121 @@ | ||
| --- | ||
| 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 | ||
| --- | ||
|
|
||
| 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. | ||
|
There was a problem hiding this comment.
What's the operational overhead mentioned here? Transaction costs? I can respect the position that one should rotate keys at some frequency, but for the average user it probably doesn't really matter. There was a problem hiding this comment. I meant users of the PKI in general, but hosts would've read more accurately. Will change. There was a problem hiding this comment. For hosting providers these are still (in the common case) one-time costs. Whether you pass that cost on to customers in some way or not, over time it'll smear out into a fraction of the cost of actually doing the hosting. Regardless, as in my other comment below, the naive L2 we currently have already solves for transaction cost. That's especially true for hosting providers, who can batch a bunch of setup transactions to prepare inventory ahead of time, do ops on large parts of the fleet, etc. There was a problem hiding this comment.
The fact that the naive rollup what implemented in the first place contradicts this in the sense that those one time costs can actually matter to hosts. The Naive rollup solves for transaction cost at the tradeoff of legibility to the rest of the blockchain, which imo actually is a big hit to the possible functionality of Urbit ID both within and without Arvo/Ames. There was a problem hiding this comment.
How? Isn't Ethereum at the level of big where anyone who does any crypto stuff at all has easy access to (or access to know-how about) an Ethereum wallet through Metamask or w/e tooling is popular? There was a problem hiding this comment. I think 'accessibility' is probably not the right word here, but rather this is a continuation of the point about optionality (thus enabling 'access' for people not interested in what Ethereum has to offer). Having your Urbit ID legible to the chain on which you do most of your blockchain activity is quite desirable. On Ethereum and EVM related chains this looks like stuff like Tokenbound Accounts (smart contract wallets controlled by the owner of your L1 Urbit ID NFT). On bitcoin it might look like derived payment addresses, on Zenith it might look like access to the hyperscry oracle, or on Solana something else entirely (not a solana enjoyer, I'll let the degens make that case). There was a problem hiding this comment.
What features are these? Do we want/need them? Why? "Future compatibility" suggests we don't have a use-case we would immediately build, which makes this more likely to atrophy/wither on the vine. There was a problem hiding this comment. See piece about ERC6551 above. Also, in regards to the specific suggestion to implement on Base first, what would afford us the benefits around all the work Coinbase is doing around tooling for passkey controlled smart wallets that take advantage of account abstraction and general UX/UI work for user onboarding. There was a problem hiding this comment. I would second the concern about building something that dies on the vine, though. |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment.
If the long-term intent is integration with a diverse range of targets, you probably want to start with integrating at least two or three very technically dissimilar targets, to prove out that your architecture can support all those different cases. Yes this increases scope, but reduces risk of unforeseen integration problems down the line. There was a problem hiding this comment. Most of your other objections seem to express concerns about scope; curious how you think about the tension between long term intent (including if you agree with it or not), and starting with reasonable size chunks and proving out the use cases (i.e. onboading users via Base and passkey wallets). |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment.
Correction: this synthesizing happens in ( |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment.
As per my comment above, jael presently has no knowledge at all of chain-specific details. I would object to putting that kind of logic in the kernel at this point in time, and especially if that logic has to relate to an ever-expanding set of sources. There was a problem hiding this comment. Agreed, Jael should continue to be unaware of any chain specific details. Logic for the varied set of sources should probably be in azimuth.hoon and fed by %eth-watcher, %base-watcher (an %eth-watcher clone w/ diff rpc endpoint), %sol-watcher, %btc-watcher, etc. Notably, having other chain watchers is also incredibly useful tooling for smart contract / dapp devs. @tocwex initially launched %fund on Eth because of the existing tooling, but having smooth ways to get chain state into ones urbit and append p2p/private data to transactions/accounts/etc is incredibly valuable. |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment.
Doesn't the added capability of point mobility radically alter the security model? That's a whole new surface area. There was a problem hiding this comment. I think the ideal case here is that we basically allow a star to push it's spawn proxy to the bridge and separate it's planets from it's point, such that in the earlier iterations of this we really are only having planets operate on other chains. This would require essentially adding bridge addresses to be addresses from which the ownership of a star could not revoke/reclaim the proxy unilaterally. This would require an onchain senate vote to modify. There was a problem hiding this comment.
Not obvious to me that there's broad consensus on whether this should be a role the galaxies should take on, whether they should be forced to take it on, or whether it should be a role exclusively galaxies can take on. There was a problem hiding this comment. As currently conceived this is a role that optionally galaxies may take on if they so chose. I would be of the mind that forcing anyone out of their current state (i.e. Ownership of their point on L1 Ethereum and no operational obligations) would be counter to the ethos of digital asset ownership. In the same way that the senate could vote to disenfranchise any particular point's owner, but would not because that is counter to the idea of ownership, the senate should not abuse minority rights in forcing them out of the current state. Providing more enticing alternatives should absolutely be on the table though. |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment. These same arguments can be made in favor of naive rollups. But we already have those. So why are they insufficient? I assume the response will be "can't move assets out of naive L2", but my understanding is that there's known ways of resolving that, so why not tackle that instead? There was a problem hiding this comment. I'm very pro-'getting rid of the naive rollup'. Would be very supportive of moving it to a different L2. Even though I generally object to Base (conceptually I just don't think any of the OP stack is 'there' yet and it being so influenced by a publicly traded US company is concerning to me), it is definitely a better option than continuing to have people stuck on the single directional naive L2. |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment.
Can you elaborate? Increasing the amount of non-urbit-native places that urbit assets can be transferred to feels like it's in conflict with that. There was a problem hiding this comment. I'll post my recent USTJ article as the 'longer form' version of how I think about this: https://urbitsystems.tech/article/v01-i02/on-the-utility-of-azimuth-and-decentralized-identity Shorter form is: https://sarlev-sarsen.rooftopdao.io/blog/why-l1masterrace-is-more-than-a-meme TL;DR: You want your identity layer to be as high-level as possible. Putting your digital identifier on the most legible system, and additionally having it portable between global consensus systems increases your sovereignty by instantiating a right to exit. This is why the naive rollup is such an abomination in my eyes; it both decreases legibility, and totally nukes the right to exit. |
||
|
|
||
| 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. | ||
|
There was a problem hiding this comment.
Not obvious to me what's meant by this exactly. |
||
|
|
||
| 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). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand what's meant by this. Is the assumption that there's a large number of people who want to use Azimuth but cannot use Ethereum for religious reasons? Or is it that there's (definitionally) more blockchain devs than Ethereum devs and we want to get that audience? (To develop... what?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a whole swath of Bitcoiners who would otherwise be very urbit aligned if it weren't for the PKI being on Ethereum. At a higher level than that, if Urbit is aiming to be a self-sovereign identity system, being tied to a single consensus layer kneecaps that capacity to pick up users of different socioeconomic networks. Users ought to be able to put their identity on the consensus network that aligns with their needs/value system. The fact that ownership on the Urbit (Arvo/Ames) Network is client side validated suggests (or proves) that we needn't be restricted to on-chain validation or single chain consensus as the incentive for any given Arvo node operator is to maintain an accurate copy of (cross-chain) Azimuth state such that they can communicate with other members of the network.