@@ -0,0 +1,220 @@
1++++
2+title = "The Gang Solves the Gas Crisis"
3+date = 2021-05-14
4+description = "How we're making Urbit ID affordable again"
5+[extra]
6+author = "Jonathan Paprocki"
7+ship = "~datnut-pollen"
8+image = "https://media.urbit.org/site/posts/essays/gas.jpeg"
9++++
10+
11+
12+
13+Anybody who has used Ethereum smart contracts recently is aware that it has
14+gotten _expensive_. There are a large quantity of
15+complicated and clever techniques each with their own trade-offs
16+that are collectively referred to as "layer 2 solutions" (see [further
17+resources](#resources) for more information about these). This is in contrast to
18+the base computational layer of Ethereum called "layer 1", which is what constitutes most Ethereum usage and where [Urbit ID](@/docs/glossary/azimuth.md)’s smart contracts currently exist.
19+
20+Tlon has always covered gas costs for Urbit ID up to a set limit, and this was easy a couple of years ago when the cost of transactions required to get a [planet](@/docs/glossary/planet.md) up and running came out to less than a dollar. Unfortunately the ongoing Ethereum gas crisis, along with the rising price of Ethereum itself, has made this impossible. We’ve seen gas costs to set up a planet as high as several hundred US dollars at time of writing!
21+
22+In response to the gas crisis, Tlon has spent the last several months developing
23+a simple, in-house layer 2 solution which we anticipate will reduce typical gas costs by 65x or more.
24+
25+This post is primarily a short non-technical explainer of the end-user experience of our solution aimed at planet and [star](@/docs/glossary/star.md) owners and those in the market for one, as well as a status update on where we're at in development. At [the end](#technical) we give some minimal technical details and resources to help you dig deeper should you wish.
26+This is also primarily aimed at those who currently self-host or plan to self-host their
27+urbit. For anybody utilizing a hosted service, this matter will all be handled
28+by your provider. There is a [separate section](#stars) addressed specifically at star owners, and another [section](#rollers) for those who wish to set up their urbit to accept and submit layer 2 transactions. We’d like to emphasize that this system is 100% opt-in—if you are satisfied with the current experience of Urbit ID, then nothing changes for you whatsoever.
29+
30+Perhaps the most pressing question held by anybody reading this is—when will
31+it be ready? It's not reasonable to give a timeline on difficult engineering
32+work, but rest assured that completing this upgrade is a top priority. Much
33+of the back-end is approaching completion, and we are confident in a release before the end of Q3 and hopefully much sooner.
34+
35+### Naive rollups
36+
37+Our layer 2 solution, designed primarily by Tlon lead engineer `~wicdev-wisryt`,
38+is known as "naive rollups" and we will be using this term interchangeably with
39+"layer 2"—though it is important to note that there are many layer 2 solutions
40+utilized by projects other than Urbit. As we're avoiding technicality here, we’re focusing primarily on the advantages and disadvantages of utilizing our layer 2 solution, and how that affects the management of your [ship](@/docs/glossary/ship.md).
41+
42+Very briefly, a rollup is a way to combine many transactions into one, and we
43+are building infrastructure so that any Urbit ship may be utilized as a "roller". A
44+roller will collect layer 2 Urbit ID transactions, compute their effects, and post the
45+result of the transactions onto the Ethereum blockchain. Anybody may set up a
46+ship to [act as a roller](#rollers). Tlon will be launching our own publicly accessible roller, but as Urbit is a decentralized network, by no means will we have a monopoly.
47+
48+#### Pros and cons
49+
50+The primary advantage to using naive rollups is that the gas cost for Urbit
51+ID-related actions will be dramatically reduced. It will be reduced sufficiently that we expect that a few transactions per ship per week (plenty for ordinary usage) submitted to Tlon's roller will not cost the end user anything. There are no gas costs associated with submitting a layer 2 transaction to a roller, and Tlon will bear the gas cost of posting the results to the blockchain. That means that the cost you see for a planet on a market that utilizes Tlon's roller ought to be
52+the final cost.
53+
54+There are a few trade-offs for this, but none of them really sacrifice the core
55+value propositions of Urbit ID.
56+
57+The most substantial one is that ships on layer 2 are essentially completely isolated
58+from the rest of the Ethereum ecosystem. They can no longer interact with smart
59+contracts designed to work with Urbit ID or non-fungible tokens (which are how Urbit IDs are represented) in general. It is also not possible to write new Ethereum smart contracts that work with layer 2 ships.
60+
61+Compounding that factor, the journey to layer 2 is one-way only—at
62+least for now. There are theoretical ways a ship may be moved back to layer 1, but they do not yet exist, and we cannot promise that such a thing will be available in a timely manner. Anybody moving a ship to layer 2, or buying a ship on layer 2, should assume that they will
63+remain on layer 2 for the foreseeable future. We do not expect this to be
64+permanent, but it is perhaps the most significant drawback for the time being.
65+
66+Another one is that transactions may no longer be "instant". Effectively, this
67+was already the case on layer 1—unless you paid a lot of gas, you could wait
68+hours or even days for your transaction to clear. But the way we are saving on
69+gas is essentially by "bundling" or "rolling up" many transactions into one, and
70+submitting them as a single transaction. The more transactions in the rollup,
71+the better the savings. This bundling is not the only factor at play here
72+though—costs are reduced other ways, but this is a technical detail
73+[discussed later in this post](#technical). It is possible to use layer 2 to submit single
74+transactions (and this will still save on gas costs!), so utilization of layer 2
75+should not incur any delay over layer 1 when utilized in this fashion.
76+
77+Tlon has not finalized the details on how our roller will work, but it will
78+probably involve waiting until a sufficient backlog of transactions have been
79+submitted to make it economical to bundle them up, or just submitting every set
80+time period, whichever arrives first. We do not see this as a big issue—we
81+view Urbit ID as "digital land", and a few hours to acquire land, or waiting for
82+your new personal computer to be delivered, is still lightning fast in
83+comparison to the real world. We also have ideas on methods that will allow you to get on the network before the transfer has been confirmed, but that is outside of the scope of this article.
84+
85+Our layer 2 preserves the main value proposition of Urbit ID, which is that your ship
86+belongs to you forever, and that this is assured by very strong cryptographic methods and
87+game-theoretic arguments comparable to the ones that exist on layer 1. We
88+consider this principle to be uncompromisable, and maintaining ultimate
89+sovereignty over your ship was totally central in choosing our solution.
90+We summarize the new security model [below](#technical), and `~wicdev-wisryt`
91+goes into greater detail in the [resources](#resources).
92+
93+### Changes to User Experience
94+
95+The primary way one manages their Urbit ID, namely performing tasks such as
96+transferring ships, setting networking keys, or setting
97+[proxies](@/docs/glossary/proxies.md), is with a web interface called
98+[Bridge](@/docs/glossary/bridge.md) found at
99+[bridge.urbit.org](https://bridge.urbit.org). If you already own a planet,
100+you've probably used Bridge before - perhaps only a single time.
101+
102+Bridge will be getting a facelift to enable easy interfacing with layer 2,
103+including loud warnings about what is being gained and lost by doing so. From
104+here you will be able to transfer your ship to layer 2, and once there,
105+perform all the usual actions you can on layer 1.
106+
107+The main difference for layer 2 transactions on Bridge will be the additional
108+choice of a roller to submit transactions to. Tlon's will be free for ordinary, non-time-sensitive usage.
109+You could use your own ship for a fast single transaction for a little more gas. We expect that planet markets and stars may wish to set up their own rollers as well.
110+
111+Every planet has a sponsor star, which distributes [OTA
112+updates](@/docs/glossary/ota-updates.md) to their sponsored planets and assists with peer discovery. Both layer 1 and layer 2 planets will be able to be
113+sponsored by either layer 1 or layer 2 stars, meaning that nothing will change
114+in terms of how sponsorship works.
115+
116+When you buy a ship, any reputable seller will inform you whether or not it is
117+on layer 1 or layer 2. Anyone running an urbit will be able to verify this information, and we expect for tools to exist to make this information publicly available (see [this grant](https://grants.urbit.org/bounties/1101665172-network-explorer-data-pipeline-http-api).
118+
119+And that's it! If you'd like to know how things will be changing for
120+[stars](#stars), what goes into [setting up a roller](#rollers), and additional
121+[technical details](#technical), read on.
122+
123+### Changes to stars {#stars}
124+
125+Both planets and stars will be able to move to layer 2.
126+[Galaxies](@/docs/glossary/galaxy.md) must remain on layer 1 for technical
127+reasons, and [moons](@/docs/glossary/moon.md) and
128+[comets](@/docs/glossary/comet.md) never interacted with Ethereum anyways, so
129+they are completely out of the picture.
130+
131+Stars will be able to remain on layer 1 with no action required. For star owners
132+that wish to take advantage of the cheaper gas costs, there are two possible
133+modes: ownership of the star on layer 2, or setting the spawn proxy to layer 2
134+with ownership remaining on layer 1.
135+
136+The first mode—a star which is owned on layer 2—has the same advantages and
137+disadvantages as a layer 2 planet. Planets spawned by a layer 2 star will also
138+necessarily be on layer 2 - there is no way to spawn a layer 1 planet from a
139+layer 2 star, though any planets which were spawned on layer 1 before the
140+star migrated to layer 2 will remain on layer 1.
141+
142+The second mode—ownership on layer 1, with spawn proxy on layer 2—is only slightly more complicated. Such a star will change its networking keys, transfer
143+between wallets, and set its management proxy all on layer 1, with the
144+corresponding higher gas cost. However, it will be able to spawn planets on
145+layer 2—and _only_ on layer 2—with the corresponding layer 2 tradeoffs. Like
146+moving ownership to layer 2, this will be a one-way journey for now. Planets
147+spawned before moving the spawn proxy to layer 2 will remain on layer 1, but
148+from then on, all planets spawned by that star will live on layer 2. Finally, stars in this second mode may transition to the first mode, but not vice versa.
149+
150+### Creating a roller {#rollers}
151+
152+
153+
154+Rollers are urbit nodes which users submit transactions to to be "rolled up"
155+into a bundle to be submitted to the Ethereum blockchain. The business logic for
156+a roller runs on the urbit node itself. Thus, anybody with an urbit ship may set
157+it up to act as a roller. While the details of how rollers work are still being
158+hammered out, one should expect that one can either set transactions to be
159+submitted at regular intervals, once a sufficient number of transactions have
160+been received (as more transactions means greater savings), manually, or some
161+combination of the above.
162+
163+Tlon plans to release documentation on how to set up your own roller concurrently with
164+the release of our layer 2 solution.
165+
166+Malicious rollers could potentially exist, but the worst they ought to be able
167+to do is simply not submit your transaction. The security factors for rollers
168+are briefly addressed [below](#technical), and elaborated upon in the
169+[resources](#resources), but you can expect full technical documentation on
170+these factors to be included in the roller documentation.
171+
172+### Changes to Azimuth
173+
174+[Azimuth](@/docs/glossary/azimuth.md) is the set of Ethereum smart contracts
175+governing Urbit ID. They will require a few changes to accommodate the new
176+system. Some of this has been implicit above, but to be clear, we will only be
177+making a couple minor alterations:
178+ - Once a star's spawn proxy is set to the layer 2 address, it can't be switched
179+ back, and they can no longer spawn layer 1 planets.
180+ - Galaxies and their proxies cannot be deposited to layer 2.
181+Some other minor details are yet to be worked out, but again, nothing will change for those who wish to remain on layer 1.
182+
183+### Technical details {#technical}
184+
185+What's really going on behind the scenes here? Briefly, only the data of the Urbit ID transactions will be posted on-chain, while computation and state storage will now happen on your ship.
186+
187+In layer 1, the [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/) guarantees the validity of state transitions, while for layer 2 transactions, each Urbit node guarantees the validity of the state transitions.
188+
189+Changes to the state of Urbit ID on layer 1 works as follows:
190+ 1. A transaction is posted to the Ethereum blockchain.
191+ 2. The EVM calculates the resulting state transition and checks its validity, then updates the state.
192+ 3. Your urbit downloads the new state from an Ethereum node.
193+ 4. Your urbit makes the final decision on whether the new state is valid.
194+
195+In practice, the fourth step is never used in layer 1. The primary change to our
196+security model is that we are cutting out step 2 and beefing up step 4. Your
197+ship will now perform validation of the transactions posted to the Ethereum
198+blockchain, rather than the EVM.
199+
200+Since [Urbit OS](@/docs/glossary/arvo.md) is deterministic, and Hoon has some nice formal
201+properties, it turns out to be a great language for writing smart contracts. Thus we are effectively swapping the Ethereum smart contract with a “Hoon smart contract” run locally on your ship.
202+
203+#### Further Resources {#resources}
204+
205+We want to keep this post brief and non-technical, so that's all we'll say about
206+it for now. To find out more, you have a few directions to go on. We held a
207+[Developer Call](@/events/2021-03-04-developer-call-scaling-azimuth.md) where
208+`~wicdev-wisryt` outlines the design in much more technical detail, and also
209+explains why we decided to utilize our own design rather than other known layer
210+2 solutions such as [Optimistic
211+rollups](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/),
212+[ZK-rollups](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/),
213+etc, or other blockchains. He also plans to do a more technical walkthrough video sometime before release. For those who would rather read, see
214+`~wicdev-wisryt`'s [RFC: Naive rollup for cheaper Urbit ID
215+transactions](https://groups.google.com/a/urbit.org/g/dev/c/p6rP_WsxLS0/m/hQBX0modAwAJ)
216+post on the `urbit-dev` mailing list. Lastly, the primary working branch on
217+Github for the Urbit side of naive rollups is
218+[here](https://github.com/urbit/urbit/tree/philip/naive), though it is not the
219+only place code is accumulating.
220+