RFC: Naive rollup for cheaper Urbit ID transactions

[Philip Monk]

One of the best gas price solutions, in my opinion, is a "naive rollup".  I've attached a description which doesn't assume much blockchain familiarity.

I like this solution because it's relatively fast to implement and reduces our dependency on external systems as low as it can go without compromising security.  Essentially it just uses Ethereum as an event log and all the computation happens inside your Urbit instead of on-chain.

It has significant tradeoffs, though.  An important way to mitigate those is to make migration purely opt-in.  That way, anyone who feels the tradeoffs aren't worth it can keep using Azimuth exactly the way it is now.  Over time, we should be able to resolve most of these issues as other technologies advance, particularly ZK proof systems.

[Jake Miller]

Do you put these RFCs in urbit anywhere? I know most of this stuff has been traditionally in email, but like entirely in urbit now and would love if i could comment / read these there. 

Would be happy to copy these to ~middev/the-forge if you'd like.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

[Anton Dyudin]

Given the economic value of "for $100 spawn an asset worth $10-$50" is presently dubious, is the "specific address" you yeet a delegate to just something Tlon-controlled? Paired with a pledge to execute the off-chain spawns if Vitalik pulls a rabbit out of a hat and makes the core Azimuth contract remotely relevant again - maybe have galaxies vote on it if you can find enough who can afford to

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

[Philip Monk]

Jake, that's not a bad idea.

Anton, I imagine the specific address has no private key, and if we find a way to trustlessly transfer ships back onto the main chain, the galaxies vote in an upgrade that specifies how to transfer out of that address (eg by proving ownership in a ZK proved hash)

[Mike Gogulski]

What would existing Ethereum-based markets like OpenSea need to do in order to support sales of planets spawned under this scheme? Or would that become impossible?

[Charlie Cummings]

Would this make a fresh boot take longer, since you would have to compute all the offchain transactions before your PKI is up to date and you can talk to any other ship? Is this already case with Ethereum via eth-spider, or do we ask a chain explorer API the current state at boot?

In general, I'm very much in favor. Expensive Ethereum onboarding is the biggest problem with Urbit IMO right now, and is only getting worse, and this seems a "simple" solution.

Re: OpenSea - all planets not sent to the "offchain" contract address would still operate per normal, right? There'd be an Ethereum transaction log of Azimuth actions, plus the Urbit computed log for any ship opted into the rollup contract.

Is there a bulk transfer function in current Azimuth that would make the initial sending of planets to the rollup contract less expensive? It's still like $20 just to transfer a ship, even if this makes Azimuth key setup "free", which stars would have to eat.

For management for end users, would there be any usability changes? Would it just be a version of Bridge that sends PKI actions to some rollup submitter instead of to normal Ethereum? Bridge would also have to compute the rollups to figure out if you actually own a point or not, I think.

[Philip Monk]

> What would existing Ethereum-based markets like OpenSea need to do in order to support sales of planets spawned under this scheme? Or would that become impossible?

Any ships still on L1 or spawned on L1 will work exactly as they do today (until sent to the rollup).  Ships sent to or spawned on the rollup will be "stuck" there, so if an exchange wanted to suport spawning/transferring them, it would need to run one of our rollup nodes (or point at one that we run), just like if they were supporting another chain.

Centralized exchanges are used to this, but for decentralized exchanges, atomic swap may be difficult or impossible to do trustlessly in the first iteration.  There are various schemes for "bridging" chains, some of which are trustless and others requires briefly trusting an intermediary.

Before too long, I hope we can use ZK proofs to be able to safely send ships back to Ethereum for use with normal smart contracts.  Within the next couple years, we should be able to send directly from our rollup to other rollups, with no transactions on the main chain.  At that point, the whole flow could happen on various rollups trustlessly:

- a star owner spawns some planets and sends them to another rollup that has a DEX (which knows about ERC20 and ERC721 standards, but nothing about Urbit)

- you go to coinbase to buy ETH, but it's not L1 ETH; it's already deposited into a rollup, so you can cheaply withdraw from Coinbase to the rollup with the DEX

- you use the DEX to swap the ETH for the planet

- you withdraw the planet to our rollup, where you set the keys and boot up your ship

All of these transactions can happen trustlessly without any of them having to run on the main Ethereum chain.  It's possibly these different rollups will end up being a single shared rollup, or we may end up in a poly-rollup world.

> Would this make a fresh boot take longer, since you would have to compute all the offchain transactions before your PKI is up to date and you can talk to any other ship? Is this already case with Ethereum via eth-spider, or do we ask a chain explorer API the current state at boot?

Currently we get a list of all transactions for breaches, key changes, and sponsorship changes, and we process them all in order.  This would make it somewhat more expensive, since you would also process transfers, management proxy address changes, etc.  Once that becomes expensive enough, IMO the correct default would be to trust a signed snapshot of the state.  For example, you're trusting whoever supplied your pill to not give you bad code, so it wouldn't be unreasonable to also trust them to include a snapshot of the PKI state.  Of course, for the truly paranoid, run from scratch: accept no substitutes!

There are also certain advantages to tracking the rollup state outside of Urbit, so it might be that for efficiency you point to a "rollup node" just like you now point to an ethereum node.  Fully verifying would be to point your ship at your own rollup node, which points at your own ethereum full node.  Most won't need this, but it's important that it's feasible.

> Is there a bulk transfer function in current Azimuth that would make the initial sending of planets to the rollup contract less expensive? It's still like $20 just to transfer a ship, even if this makes Azimuth key setup "free", which stars would have to eat.

A reasonably straightforward set of "bulk transfer" options we could support are:

- Transfer a star, then all planets will be spawned on the rollup

- Set the spawn proxy of a star, then all planets will be spawned on the rollup, but the star itself could be transferred on L1.  Note this is still irrevocable -- you wouldn't be able to change the spawn proxy back to an L1 address.

- Use the setApprovalForAll function (from ERC721) to transfer all ships owned by a particular address to the rollup at once.  This would be irrevocable in the same way as the spawn proxy.

- Maybe specifically support the star lockup contracts, so that you could transfer your entire batch to the rollup at once.  I don't think we could split up batches, so this would probably be mainly useful once we have a way to send ships back to the main chain, since I doubt people will want to send their whole batches to the rollup

> For management for end users, would there be any usability changes? Would it just be a version of Bridge that sends PKI actions to some rollup submitter instead of to normal Ethereum? Bridge would also have to compute the rollups to figure out if you actually own a point or not, I think.

Yeah, it should be pretty similar for end users, just bridge would need to read from a rollup node (which could be a ship we run, a standalone program, or actually processed inside bridge) and write to an aggregator.  It would also have a function to deposit your ships to the rollup, and it must clearly communicate the pros and cons of doing so.

On Sun, Feb 21, 2021 at 9:37 AM, Charlie Cummings <chc...@gmail.com> wrote:

Would this make a fresh boot take longer, since you would have to compute all the offchain transactions before your PKI is up to date and you can talk to any other ship? Is this already case with Ethereum via eth-spider, or do we ask a chain explorer API the current state at boot?

In general, I'm very much in favor. Expensive Ethereum onboarding is the biggest problem with Urbit IMO right now, and is only getting worse, and this seems a "simple" solution.

Re: OpenSea - all planets not sent to the "offchain" contract address would still operate per normal, right? There'd be an Ethereum transaction log of Azimuth actions, plus the Urbit computed log for any ship opted into the rollup contract.

Is there a bulk transfer function in current Azimuth that would make the initial sending of planets to the rollup contract less expensive? It's still like $20 just to transfer a ship, even if this makes Azimuth key setup "free", which stars would have to eat.

For management for end users, would there be any usability changes? Would it just be a version of Bridge that sends PKI actions to some rollup submitter instead of to normal Ethereum? Bridge would also have to compute the rollups to figure out if you actually own a point or not, I think.

On Sun, Feb 21, 2021, 11:16 AM Mike Gogulski <mike@gogulski.com> wrote:

What would existing Ethereum-based markets like OpenSea need to do in order to support sales of planets spawned under this scheme? Or would that become impossible?

On Sun, Feb 21, 2021 at 4:18 PM Philip Monk <philip@tlon.io> wrote:

Jake, that's not a bad idea.

Anton, I imagine the specific address has no private key, and if we find a way to trustlessly transfer ships back onto the main chain, the galaxies vote in an upgrade that specifies how to transfer out of that address (eg by proving ownership in a ZK proved hash)

On Sun, Feb 21, 2021, 02:06 Anton Dyudin <ohAitch@gmail.com> wrote:

Given the economic value of "for $100 spawn an asset worth $10-$50" is presently dubious, is the "specific address" you yeet a delegate to just something Tlon-controlled? Paired with a pledge to execute the off-chain spawns if Vitalik pulls a rabbit out of a hat and makes the core Azimuth contract remotely relevant again - maybe have galaxies vote on it if you can find enough who can afford to

On Sat, Feb 20, 2021 at 21:43, Jake Miller <jraydermiller@gmail.com> wrote:

Do you put these RFCs in urbit anywhere? I know most of this stuff has been traditionally in email, but like entirely in urbit now and would love if i could comment / read these there. 

Would be happy to copy these to ~middev/the-forge if you'd like.

On Fri, Feb 19, 2021 at 4:14 PM, Philip Monk <philip@tlon.io> wrote:

One of the best gas price solutions, in my opinion, is a "naive rollup".  I've attached a description which doesn't assume much blockchain familiarity.

I like this solution because it's relatively fast to implement and reduces our dependency on external systems as low as it can go without compromising security.  Essentially it just uses Ethereum as an event log and all the computation happens inside your Urbit instead of on-chain.

It has significant tradeoffs, though.  An important way to mitigate those is to make migration purely opt-in.  That way, anyone who feels the tradeoffs aren't worth it can keep using Azimuth exactly the way it is now.  Over time, we should be able to resolve most of these issues as other technologies advance, particularly ZK proof systems.

--

To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@urbit.org.

[John Franklin]

Typo in naive-for-martians.txt: Etheruem (line 141).

On Monday, February 22, 2021 at 11:21:20 PM UTC-6 phi...@tlon.io wrote:

> What would existing Ethereum-based markets like OpenSea need to do in order to support sales of planets spawned under this scheme? Or would that become impossible?

On Sun, Feb 21, 2021 at 4:18 PM Philip Monk <phi...@tlon.io> wrote:

Jake, that's not a bad idea.

Anton, I imagine the specific address has no private key, and if we find a way to trustlessly transfer ships back onto the main chain, the galaxies vote in an upgrade that specifies how to transfer out of that address (eg by proving ownership in a ZK proved hash)

On Sun, Feb 21, 2021, 02:06 Anton Dyudin <ohA...@gmail.com> wrote:

Given the economic value of "for $100 spawn an asset worth $10-$50" is presently dubious, is the "specific address" you yeet a delegate to just something Tlon-controlled? Paired with a pledge to execute the off-chain spawns if Vitalik pulls a rabbit out of a hat and makes the core Azimuth contract remotely relevant again - maybe have galaxies vote on it if you can find enough who can afford to

On Sat, Feb 20, 2021 at 21:43, Jake Miller <jrayde...@gmail.com> wrote:

Do you put these RFCs in urbit anywhere? I know most of this stuff has been traditionally in email, but like entirely in urbit now and would love if i could comment / read these there. 

Would be happy to copy these to ~middev/the-forge if you'd like.

On Fri, Feb 19, 2021 at 4:14 PM, Philip Monk <phi...@tlon.io> wrote:

One of the best gas price solutions, in my opinion, is a "naive rollup".  I've attached a description which doesn't assume much blockchain familiarity.

I like this solution because it's relatively fast to implement and reduces our dependency on external systems as low as it can go without compromising security.  Essentially it just uses Ethereum as an event log and all the computation happens inside your Urbit instead of on-chain.

It has significant tradeoffs, though.  An important way to mitigate those is to make migration purely opt-in.  That way, anyone who feels the tradeoffs aren't worth it can keep using Azimuth exactly the way it is now.  Over time, we should be able to resolve most of these issues as other technologies advance, particularly ZK proof systems.

--

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.

--
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@urbit.org.