You don't need to be born as L2, you can become an L2.
This is a thread about L2s, bridges and why Aurora architecture allows it to be treated as one of the best-designed Ethereum scalability solutions.
🧵
First, let's start with an L2 definition. I will use the most common one from @l2beat: an L2 is a chain that fully or partially derives its security from L1 Ethereum.
In short, zkSynk, Arbitrum and Optimism are L2s; Polygon is not.
To put another perspective on L2s: in order to break an L2 you would need to break Ethereum. If it's not the case, then this is not an L2.
Aurora is working as a smart contract on NEAR, so if you want to break Aurora, you need to break NEAR. And from the first sight it is not an L2, right?
Well, that would be true, if not for the Rainbow bridge.
rainbowbridge.app/
Rainbow bridge is a trustless bridge, that has a simple idea in its' core: in order to pass the message (or tokens) from one chain to another, you need to have a light client of the source chain deployed as a smart contract on the target chain.
aurora.dev/blog/2021-how-the-rainbow-bridge-works
Surprisingly, this design makes the source chain an L2 of the target chain!
Indeed, if the source chain is compromised, one need to compromise the light client on the target chain too to allow for the stealing of the funds.
Pro notice: the above works for reordering/retrospective attacks with any light client and if the latter supports checks of the invalid state transitions, then it's fully correct.
Since NEAR light client is implemented as a smart contract on Ethereum, NEAR as a whole and Aurora in particular is an L2 to Ethereum.
Though without Rainbow bridge these are just alternative L1s. Insane, right?
Now the thing that is important for L2s is the risks that they incur for the users. Let's do a quick overview of what is tracked by @l2beat (one can read about the risks in detail in their FAQ).
l2beat.com/?view=risk
1. State validation is how one can validate the L2 state on L1?
2. Data availability is whether a user can recreate the L2 state on L1.
3. Upgradeability is whether some party can upgrade the L2 solution unilaterally or not.
4. Sequencer failure: is there anything that a user can do on L2 if L2 progression is stop happening
5. Validator failure is whether a user able to withdraw from L2 to L1 if L2 validation is stopped.
Latter two risks are specifically important, since usually L2s are not focused on decentralisation: Ethereum security is enough and the fact that L2 might have even a single centralised sequencer (~validator) is omitted.
With respect to this problem, Aurora architecture is the best that the world can offer: instead of using a centralised sequencer, it uses... NEAR validators. Which are decentralised enough to say that realistically, it won't be broken / stopped due to DoS / collusion.
The decentralisation of NEAR validators delivers an additional great feature -- censorship resistance: if a user wants to transact on Aurora, he is always able to do it.
A note on upgradability: Rainbow bridge contracts are multisig upgradeable with an ability to pause the contracts for a wider set of accounts.
This is particularly important in the current state of the world when bridges are hacked over and over again.
If you didn't read the thread on how Rainbow bridge systems automatically stopped the attack in May, I encourage you to do so:
twitter.com/AlexAuroraDev/status/1520810591803293696
Upgradeability of the Rainbow Bridge may be dropped at any time, but it is extremely inconvenient for the users. Un-upgradeable, Rainbow will work only within one Ethereum hardfork, forcing users to move to the next version once the the next hardfork is in the vicinity.
This only can be fixed with making Ethereum consensus available on the smart contract level, which is not a priority for EF.
And that's a pity, since it would allow for decentralised, mutually-enriched future of interconnected L1s (through properly designed bridges).
Summing above, if one would add Aurora to the list of L2s on l2beat (which is not the case ATM), then it would look like the following:
And a closing note.
Ethereum light client is a contract on NEAR blockchain. And this means only one thing: Ethereum is an L2 to NEAR :)