UIP-0131: Ministry, an Azimuth Multibridge #69
Conversation
add header
change category
remove header
|
Seems interesting—I'm admittedly a bit out of the loop since my days on Bridge. What makes Ethereum cost-ineffective? |
|
who has said they want NFTs on other chains? what problem are you solving? Why would you fracture liquidity across ecosystems when there's none right now? This appears to me another one of curtis's solutions in search of a problem, and frankly getting galaxies to participate en masse does not seem likely to me. |
|
and if the stated goal is something like "we need more people building on azimuth so we should make so that we can access some new subset of builders" - what customer conversations have you had to validate that need? If the answer to that question is none, then we should focus no community energy on this. |
There was a problem hiding this comment.
Comments on UIP contents below.
Overall, I can't say I really understand the motivation for this from just reading the document. And the motivation for work like this needs to be really good because the cost is really high:
Any and all integrations you do here will have to be carried forward, in perpetuity, forever. I'm unconvinced we would pull the plug on any particular integration in practice.
When we built Azimuth (as PKI!) on Ethereum, some warned that we would never get off Ethereum. Maybe they're right, it seems somewhat unlikely at this point in time, but still a lot more likely than migrating off of however many chains this would end up integrating. Do we really want our PKI to be beholden to other projects forever?
| 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. |
There was a problem hiding this comment.
limiting Azimuth to a single chain restricts user optionality
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.
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.
|
|
||
| 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.
reduces operational overhead for users
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.
over time it'll smear out into a fraction of the cost of actually doing the hosting.
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.
|
|
||
| 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.
Integration with multiple blockchain ecosystems increases accessibility
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).
|
|
||
| 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.
Integration with multiple blockchain ecosystems (...) enables future compatibility with (...) features available on select global consensus ledgers other than mainnet Ethereum.
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.
|
|
||
| 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. |
There was a problem hiding this comment.
Base provides an ideal first target (...)
This implementation will validate the Ministry protocol architecture
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).
| 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.
The design establishes Ethereum as the senior chain to preserve the existing security model while enabling point mobility.
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.
| 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.
Using galaxies as oracles leverages the network's existing power structure and economic incentives rather than introducing external validators.
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.
|
|
||
| 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. |
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.
optimizes for sovereignty
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.
|
|
||
| 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. |
There was a problem hiding this comment.
while allowing technical implementation to adapt through the Core Guild
Not obvious to me what's meant by this exactly.
Who has said they want personal servers?
If you wanted to send USDC to ~master-malwyl right now, how would you do it? My dominion is %l2.
Can you explain what you mean by liquidity? The bridge has no significant connection to financial speculation.
Perhaps it is!
Senate quorum would be strictly advised to approve development, but not for operation. |
|
I made some specific comments above, but I think it's fair to say this proposal includes some assumptions (or at least I am making some assumptions about the context) which could be included into the doc itself. I tend to be a long-winded over explainer, so perhaps I've overfiltered re: my inputs to this doc on context setting and such, but I also think this type of back and forth, questioning, clarification and revision from the community is good for getting us all to the right place for the identity layer of the 500 year computer. To list a few of the assumptions as I see them:
Pointing all this out because even if there is debate around the edges, lots of implementation details to hash out, or experiments to run, I think the thing that we are all in agreement on is: |
Proposes bridge architecture enabling points to move between chains while maintaining Ethereum as root of trust. Initial implementation targets Base L2. Seeking feedback on design and rationale.