General-Purpose Layer 2 Static-Calls Proposal Presentation by Vitalik Buterin at ENS Online Workshop 2020
One of the highlights of the ENS Workshop this week was that Vitalik presented from Singapore (at 12 midnight) as the first speaker to kick things off.
Recap
You can see his talk starting at 5:18, and here is his presentation slides with some notes, Q&A ,and comments from Nick Johnson at the end of the presentation.
5:18 Problem & Goal
- ENS should support as many L2s as possible
- ENS should support non-EVM L2s
- Reading operations should not incur transactions.
8:43 General Approach
We are expecting that L2 will respond with the correct output_data. Given that you trust the specific L2 by the time you transfer your domain, you are already trusting the L2 so it is not adding an extra layer of trust.
12:30 Overall flow
- Step1 = Lookup the name on L1 (
vitalik.status.eth) - Step2 = If it’s not there, lookup if the parent name on L1 (
status.eth) - Step3 = If 1&2 says it’s on a specific L2, then do the challenge game
14:26 The Challenge game
Q:From Hadrien Croubois
So if I want to make sure my domain is resolved properly, and I want to use layer 2 resolution, I need to prevent anyone from registering it on layer 1 ….
A: From V
It is important that no same name exists in both L1 and L2.
Once a name (eg: status.eth) moves to a specific L2, then all the subdomains follow to the same L2.
17:36 The challenge game (with diagram)
Q: From alexvandesande
@vitalik is there any reason to have the FULL historical record? Seems it would make sense for attesters the latest N blocks only and after say 24h then all is snapshotted
A: I don’t want to make assumption in L2 how it treats the history, but any sensibly designed L2 shouldn’t have to have full archive history.
Q: From RicMoo (ether.js + Firefly)
Do we possibly need to add a bound on block_number? Otherwise I could build an attester that always returns { value: null, blockNumber: 0 }. I’m not sure of the consequences, just curious if I can DOS the challenger network by gibbing it full of useless attesters, which aren’t lying, so get their funds back, but don’t provide useful data.
(oh… I think you just answered that with the 24 hour bounds)
A: This spec does not specify how exactly attester response so it has minimalistic spec. It can demand requester to have certain block number but I didn’t want to limit the design scope, but we can change the protocol.
Q: From Brantly Millegan
How does this impact composability?
A: It will affect it in the same way as any proposal to handle domains in L2. If a domain exists in certain L2, then you can only do synchronous call within the same L2.
25:41 Security properties
28:43 Not covered here
29:30 Comment from Nick
1. There seems some interesting edge cases when the domain changes ownership at L1 as attestation from the old system may become invalid which we need to design carefully.
2. We already started thinking about making changes on how wildcard works (eg: *.status.eth) which requires changes in resolver contract. We could potentially have a wildcard attester which would allow systems to adopt both L2 delegation as well as solving wildcard support without solving each one of them. Although that would require to validate historical state in L1 which is problematic.
3. Concern: If the challenge network which Vitalik described has to apply all to all there will be scaling issue as it is equivalent to broadcasting every DNS lookup. If not, then there needs to be a way where requesters can be guaranteed to see the broadcasted message to verify that the attestation is correct.
31:50 End
The more detailed spec is posted to Ethereum Magician’s forum. If you want to dive into further conversation, I suggest you post there.
There are still lots of unspecified details so this could be a perfect idea to prototype at the upcoming EthOnline hackathon as well.
