search

urbit / azimuth

General-purpose PKI on Ethereum
MIT License
134 stars 36 forks source link

Contract upgrade proposal 002: Preparation for Naive Rollups #43

Closed philipcmonk closed 3 years ago

philipcmonk commented 3 years ago

This contract upgrade proposal is preparation for the release of naive rollups. We generically refer to this as "Layer 2" (or "L2") in contrast to the Ethereum-native transactions we use currently ("Layer 1", "L1").

Naive rollups are a technique where transactions are submitted in batches to Ethereum but interpreted off-chain by each person's ship. This is much more efficient, and we expect it to reduce gas costs by 60-100 times.[0] See more details here.

L2 will be optional. To use it, you will "deposit" a ship to L2, and from that point you'll be able to use the cheaper transactions. If you don't deposit your ships to L2, your experience will not change (including that your gas costs will not be reduced).

Importantly, if you deposit a ship to L2, it will no longer be able to interact with generic Ethereum-native tools. For example, you will not see it in your wallets (except Bridge), and it will not be able to interact with smart contracts, such as multisig or atomic swap contracts. Once you deposit a ship to L2, it cannot be sent back to L1.

The exact semantics of our implementation of L2 are nearly complete, and the user experience is under development. You can see our work in progress here, and we will explain the code and system more in the future.

This brings us to the contract upgrade proposed here. The only change that needs to happen to the existing L1 contracts is that we designate a special address[1] representing L2, so that transferring a ship to that address means to deposit it to L2. This has no bearing on the specific semantics of L2, which will be decided separately.

Specifically, this contract upgrade implements various restrictions[2] on ships which have been transferred to this address or which have set their spawn proxy to this address. All other ships will be unaffected.

These changes are fairly small, and we include tests, but any upgrade is a risk. We invite everyone to examine these changes and ask questions if any part is concerning or unclear to you. We intend to submit this contract upgrade proposal to the galaxies for a vote soon.

[0] Note this reduction is in the amount of "gas" required, whose price is determined by a market denominated in ETH. Thus, we cannot guarantee that costs will remain cheaper in USD terms, only that L2 transactions will be 60-100x cheaper than the equivalent ethereum-native ("L1").

[1] The choice of address is arbitrary except that it must be obvious that nobody has the private key for it. The address proposed is 0x1111111111111111111111111111111111111111. It's helpful if the address is recognizable, and Azimuth does not allow sending ships to 0x000.... Also proposed was 0x222..., but "crooked" numbers are not as distinct, which makes them less recognizable. Oxfff... would also be reasonable, but that has a slighly increased likelihood of triggering overflow errors in poorly written client software.

[2] Specifically:

Fang- commented 3 years ago

Also noticing that CI didn't run for 16378a5 and wondering what's up with that.

philipcmonk commented 3 years ago

Might have confused it with a several force pushes

philipcmonk commented 3 years ago

Added tests. @Fang-, can you look through them thoroughly, and also think if there's other tests that would be useful?

The one test I don't have yet is to check that you can't deposit a ship owned by a contract. I think I might need to introduce a contract which can own a ship to be able to do this.

philipcmonk commented 3 years ago

I believe this is ready to go. I've marked this as ready for review and updated the description of the pull request with details.

Fang- commented 3 years ago

As of this transaction, voting on this upgrade, targeting 0xa5b6109ad2d35191b3bc32c00e4526be56fe321f as the new contract, has started. Votes can be cast within the next thirty days, or until an absolute majority is reached, whichever comes sooner. Voting can be done using Bridge, or a generic Ethereum tool of our choosing.

The contract's source code can be viewed here and should match this PR.
Instructions for testing the upgrade are as follows:

1) check out this branch, npm install, 2) npm run fork-mainnet, wait for it to become ready, 3) in a separate terminal, npm run test-upgrade -- --target='0xa5b6109ad2d35191b3bc32c00e4526be56fe321f', 4) wait patiently for tests to pass, this can get slow.

Fang- commented 3 years ago

Voting has concluded with 76 votes in favor, 0 against. As of this transactions, the upgrade has been applied. Thank you to all who participated in the vote! Merging.