---
# System prepended metadata

title: 'Eth Magicians, 2 march 2023'

---


# Eth Magicians, 2 march 2023

Notes from chaals, edits welcome.

## Future of the magicians...

Annett: hosted a panel on how decisions get made in Ethereum. Conclusion was that governance is kind of closed, only certain decisions makers get a say. People can do something about it but you need to drive your idea hard. Controversial things can be too hard for core deves to decide on. 
Being loud and marketing an EIP are not core dev skills.

chaals: our responsibility to listen if we want to make it better

Annett: We try not to have leaders, but it's not about being able to take the decisions.

Tomiwa: Can you summarise the key points in EIP-1559 and how you got to consensus

Jamnet: It was really hard with lots of posts (dozens).

Jamie: We should do that but I don't have it in my brain now.

??: I was converted, when there were demonstrations of what would happen, not just claims that the tokenomics are good.

Jamie: There were people all over the place, but a simulation or a good technical argumetn made a difference. Ultimately it's core-devs. They know eah other and trust each other - but not you. They decide.

Annett: and I don't have enough time. Looking for people to keep things going, who aren't us.

Tomiwa: have you thought of EF getting a grant to pay someone?

JamAnnett: Money isn't the problem it's getting people who can reliably do the work.

Chaals: I have some time and experience.

## Kyle's talk

(not copying slides)

Kyle: I chose to die on a hill so we could get links in EIPs. Want to see the governance help that, because it enables or disables good practice.

process documents are living, and problems lead to evolution. E.g. W3C moving away from TimBL as BDFL.

Governance sounds boring, but is important to make a smooth system for developing the work. Our decentralised ethos leaks into governance where we are trying to coordinate with each other.

We're a standards body. Let's look at how others work.

Feels like EIPs are the standards incubation process. But W3C has established hard powers. Who can decide on a merge, or delete a post? We don't see them being abused. There's soft power - PoBV consensus...

W3C is pay to play, that drives some poeple away. But chartering establishes scope for a problem, and where to record objections.

When writing a standard you don't run out of time or money, just patience.

Standards is the politics of technical work.

W3C has a repo for each group, sometimes per spec. That means you can track every issue as a githb issue and work out what happened to it.

TAG is an elected governance body - https://w3.org/2001/tag (a bit like a more scoped version of EIP editors).

Chaals: Candidate Rec is about proving that it gets implemented and that it works.

Kyle: Adoption is actually important.

Chaal: notes that Director is replaced, for dealing with formal objections, by combinations of Advisory Board plus TAG.

Kyle: IETF has no members holding hard power, but similar processes.

Chaals

Tomiwa: companies drive decisions, in eth it is individuals. Do you see that changing?

Annett: Pooja could answer that.

Kyle: It's tricky. People representing organisation are independent engineers, but what you see is what you care about. Chrome engineers represent their own views and aren't google bots. But because of what they see as issues, that significantly influences what they care about.

Chaals: There are businesses hiring people as individual representatives, there are as Kyle said individuals influenced by where they come from.

Tomiwa: If I am a company, I have an incentive to manage magiciaisn, and steer conversations.

Kyle: Important to establish hard powers to put soft powers in balance. It's never perfect, it is politics. Politics is is the art of working together to solve problems. Imprtant to be able to represent your opinions, and to represent your business opinions.

The process is about discussion - need to recognise the games that are played so we have processes that can actually work with reality and get us the ability to do work that kind of matches our principles.

Participation is always hard, especially when it's about doing the actual work. Hence editors...

Testing is important, advocating for it in wallets and want test suites. Does our code actually interoperate? (Otherwise no need for a standard, just make what you want).

I dont see EIP having a final objection and resolution process, it's just the EIP editors being able to decide.

So if a single editor disagrees we can stop work, that's a point of centralisation.

IETF has working groups to establish process and update it. Think it would be good for us to understand how to do this, establish a governance working group of some sort and establish a process.

Jamie: Like horizontal review, and it's hard to make it work.

Kyle: If I got one thing it would be a point in the process to get hard objections and how they are resolved. Note the editors aren't bad, they are doing a job.

???: Have you considered using a DAO structure?

Kyle: there are a lot of trade-offs, and this isn't my thing.

Jamie: Been widely discussed.

## Victor - ERCref.

difference between core EIPs and ERCs - whether you need to build them into a client.

To get adoption, contribute to a project, make reference implementations

the biggest power of a standard is adoptions.

Thomas: What about companies that bypass ERCs because they have a lot of customers.

Victor: Yeah, that's a problem inherent to the space.

likewise, when developers are frustrated because the process is slow and they just write code and ship it, that's a signal that we are not meeting the needs of the community

===

## Ethers 6

standard errors so you can recognise them - and the machine can too without needing to pick which version of the message it got.

Q: how do you know what you're getting as an error?

A: yeah, tables of messages are fragile.

Victor: HTTP has standard error codes. There are proposals to do this for Eth. Anything promising?

A: We had a monthly meeting to discuss standard JSONRPC errors. Have talked to 3 other teams working on that, never got there. Would be nice to see this happen. But issues - what block number do you mean? Did you prune the transaction and return null, or did it not exist.

balances on blocknumbers only work on archive nodes. Never never hav silent errors.

It will happen... someday... please!!

comment: Seen this too. In execution API they are starting to do these.

A: It's obvious for the developer or the client... but not to the user.

followup: would be good if these things were documented

A: it's a mess.

(fetching remote content).

Kyle: Have you thought about sending it through Tor?

A: That's why we have an extension point, so we don't have to massively expand the core code but can allow this.

Victor: how do you register your extension so people can discover them and re-use them?

A: You can register your own gateways. You could have an NPM library that people could import.

I don't want Ethers to have everything built in - you create a massive monster of optional mess.

Might add an ext package to the repo. It becomes hard to manage and I don't want to endorse random things.

Daniel: Have you thought of IP-masking default? (Developers can make it but many would do it badly...)

A: Who would manage this...? I don't want to manage people's data, but I need to work out what is being used, 

/me wonders if there is some system that can hold code where you pay somehow for running the code, and anyone can deploy that and people can see what gets used...

Kyle: There is a thing that works on this sort of problem.

A: I want the people who use this to understand the security properties of what they are doing...

## lightning talks

### Ernesto - OpenZeppelin. Adding errors to library @@

We need to agree on what the error is, don't want to make them huge. Propose EIP 6093 for designing new errors. Define subject, information, ordering, can be supported by libraries. UX improvement telling you what went wrong instead of "computer says no".

Would love to hear comments. improves gas usage against revert streams.

Chaals: There are people who analyse traffic, and might have experience that helps make it work

Daniel: How do you handle non-valid changes?

Ernesto: We propose "invalid sender" on ERC-20 (for example).

A: Want to see machine-readable errors. A code, and then the information. So e.g. a wallet can do helpful things to explain to a user what went wrong and *HOW TO FIX IT*

Ernesto: Yeah. The more information we have, the more abstractions we have to build to document.

### Alex, EIP 5604

[slides]

transactions are governed by actual laws. In future I think digital assets will be important, so allow NFT to be used as collateral and put a lien on it (i.e. put some of it in escrow)

So instead of transferring ownership of your collateral you provide a [lien](https://en.wikipedia.org/wiki/Lien) over it.

Animated explanation.

Ask Victor the technical questions please :)

Q: Have you looked at other standards for loaning NFTs? Isn't approving also loaning to a contract.

Victor: Some loaning is like having an in-place approving call. We believe if the owner can withdraw the approval you don't have a lien because you provide no security.

### EIP 5023 - shareable NFTs Jarno Marrtila
[slides]

anti-rival goods are things that have network effect benefit - the more people use the good (or service), the more valuable it is.

These NFTs capture what you have done in a community.

You decide what sharing means - copying, splitting, ...

Q: When you say copy do you mean a new NFT-721, or ...?

A: We implemented it like that. But it's up to you when you use it

Q: What if you share an NFT with someone then lose the keys? How many times can you share?

A: If you lose the keys, you lost them. For sharing limits, you can decide that. Build logic around it if you want, e.g. to limit the sharing depth...

### Jack, from EthSign EIP 6066

signature validation method for NFTs. Based on 1271, verifying a signature.

Making it so anyone can use an NFT (supporting 6066) to make digital signatures. 1271 can act as a pass-through, in this you cannot pass them- has to be made by the NFT itself. Use case is e.g. using transferable ownership of NFT to represent roles on an org chart. You signed a deal, and the signatures are tied to a private key, so an individual not someone holding a role.

Kyle: Is 1271 finalised?

A: Yep.

Kyle: Otherwise the question would be have you reached out to them to figure out how to manage the use cases together.

### ?? changing trading within NFTs

5173 introduce future rewards for 721s. Now thinking about more ideas... for divisible NFTs. When you trade financial assets, and they change value, can you make them divisible. Also staking promimses a percentage, looking at new approaches.

Also looking for developers.

[Adjourned - we finished on time! Thanks to everyone...]



