Native Account Abstraction #003

hello chat

hello

gm

gm

gm

gm

https://github.com/ethereum/pm/issues/2206

I believe Chris has some updates?

Yes have a bit to share but wont need too much time

i would be interested also in dropping eip-8250 in favor of just a canonical frame like we have for expiry

Reacted to "i would be intereste..." with 👀

Reacted to "i would be interested also in dropping eip-8250 in favor of just a canonical frame like we have for expiry" with 👀

Replying to "i would be intereste..." could stay in the eip, but just not be a core protocol change

you meant eip-8272 (recent roots)

8250 is keyed nonces

Reacted to "i would be intereste..." with 👀

It shouldn't be updated in the verify frame afaik

Reacted to "It shouldn't be updated in the verify frame afaik" with 👍

Reacted to "It shouldn't be updated in the verify frame afaik" with 👍

Reacted to "It shouldn't be up..." with 👍

Since updating requires additional storage access to recompute the root

We've deployed a permissioned frames transactions testnet for people to test the feature and for clients to join permissionlessly (contact us for deposit tokens). We plan to maintain it until there's an EthPandaOps official devnet. All info in https://faucet.frames.ethrex.xyz We also have a Hegota devnet which includes more EIP implementations (EIP-8250, EIP-8272, EIP-7805, EIP-7906, a Native UTXOs PoC, and EIP-8369). This is currently a closed only-ethrex devnet. All info in https://faucet.hegota.ethrex.xyz

Reacted to "We've deployed a permissioned frames transactions testnet for people to test the feature and for clients to join permissionlessly (contact us for deposit tokens). We plan to maintain it until there's an EthPandaOps official devnet. All info in https://faucet.frames.ethrex.xyz We also have a Hegota devnet which includes more EIP implementations (EIP-8250, EIP-8272, EIP-7805, EIP-7906, a Native UTXOs PoC, and EIP-8369). This is currently a closed only-ethrex devnet. All info in https://faucet.hegota.ethrex.xyz" with ❤️

Reacted to "We've deployed a permissioned frames transactions testnet for people to test the feature and for clients to join permissionlessly (contact us for deposit tokens). We plan to maintain it until there's an EthPandaOps official devnet. All info in https://faucet.frames.ethrex.xyz We also have a Hegota devnet which includes more EIP implementations (EIP-8250, EIP-8272, EIP-7805, EIP-7906, a Native UTXOs PoC, and EIP-8369). This is currently a closed only-ethrex devnet. All info in https://faucet.hegota.ethrex.xyz" with ❤️

Reacted to "We've deployed a p..." with ❤️

Reacted to "We've deployed a permissioned frames transactions testnet for people to test the feature and for clients to join permissionlessly (contact us for deposit tokens). We plan to maintain it until there's an EthPandaOps official devnet. All info in https://faucet.frames.ethrex.xyz We also have a Hegota devnet which includes more EIP implementations (EIP-8250, EIP-8272, EIP-7805, EIP-7906, a Native UTXOs PoC, and EIP-8369). This is currently a closed only-ethrex devnet. All info in https://faucet.hegota.ethrex.xyz" with ❤️

Reacted to "We've deployed a per..." with ❤️

A réagi à "We've deployed a p..." avec ❤️

Reacted to We've deployed a per... with "❤️"

A réagi à "It shouldn't be up..." avec 👍

@Chris - Base could you share the excalidraw?

Is 7851 intended to go with 8141?

ok just to clarify the 16 recent roots just mean a given txn can reference up to 16 already published roots (so what I said earlier wasn't correct) and each referenced root must be checked against contract storage, which consumes gas but if we do a separate accounting for this so that it's not part of the verify gas it sounds good to me

Replying to "Is 7851 intended to ..." right now i’m hoping for this instead of 7851, but principle is similar https://eips.ethereum.org/EIPS/eip-8298

Reacted to "ok just to clarify the 16 recent roots just mean a given txn can reference up to 16 already published roots (so what I said earlier wasn't correct) and each referenced root must be checked against contract storage, which consumes gas but if we do a separate accounting for this so that it's not part of the verify gas it sounds good to me" with 👍

Reacted to "right now i’m hoping for this instead of 7851, but principle is similar https://eips.ethereum.org/EIPS/eip-8298" with 🙏

Reacted to "ok just to clarify the 16 recent roots just mean a given txn can reference up to 16 already published roots (so what I said earlier wasn't correct) and each referenced root must be checked against contract storage, which consumes gas but if we do a separate accounting for this so that it's not part of the verify gas it sounds good to me" with 👍

wait we can’t remove nonce

Replying to "wait we can’t remove..." hmm i guess if you require the call in the frame to a system contract to handle it

Reacted to "ok just to clarify the 16 recent roots just mean a given txn can reference up to 16 already published roots (so what I said earlier wasn't correct) and each referenced root must be checked against contract storage, which consumes gas but if we do a separate accounting for this so that it's not part of the verify gas it sounds good to me" with 👍

@Chris - Base do you mind explaining again the purpose of: selector The AA precompile

Reacted to "@Chris - Base do you mind explaining again the purpose of: selector The AA precompile" with 👍

Can you share your screen?

The excalidraw

Reacted to "The excalidraw" with ❤️

But isn’t the first 4 bytes of frame.data the selector?

Reacted to "But isn’t the first 4 bytes of frame.data the selector?" with ➕

Reacted to "But isn’t the first 4 bytes of frame.data the selector?" with ➕

how do clients feel about removing the signature list and instead having a frame mode SIGNATURE which can point to a precompile? i think ultimately the behavior will be quite similar, it should clean up the ARBITRARY handling. the main downside is every tx will need 20 bytes to select the signature scheme instead of 1

Afaik SLOAD outside of tx.sender is blocked on VERIFY on public mempools we might need to waive that requirement to be compliant?

Yeah we would need to relax that to also allowing associated storage, so account keys can be loaded from the keystore contract

Reacted to "Yeah we would need t..." with 👍

Reacted to "Yeah we would need to relax that to also allowing associated storage" with 👍

Replying to "@Chris - Base do you..." Nudge on the second point 🙂

Reacted to "Nudge on the second point 🙂" with ➕

Replying to "how do clients feel ..." What would be the difference with a VERIFY frame? That it is pure?

Replying to "how do clients feel ..." the difference is that we would elide the calldata in certain circumstances

Replying to "how do clients feel ..." Similarly to 8288? Maybe there is a way to unify it with the STARK frame?

Replying to "how do clients feel ..." 8288: https://github.com/ethereum/EIPs/pull/11772

we need something like 8288 for PQ private txns though

Reacted to "we need something li..." with 👍

I am not aware of any non-STARK-based aggregation for PQ-signatures that is practical, do you have any anything specific in mind?

Reacted to "I am not aware of any non-STARK-based aggregation for PQ-signatures that is practical, do you have any anything specific in mind?" with ➕

Reacted to "we need something like 8288 for PQ private txns though" with 👍

https://github.com/leanEthereum/leanVM

https://github.com/leanEthereum/leanVM-b for the non-Poseidon version

Makes sense.

https://excalidraw.com/#json=RFLiIvDMfjJBbWARoJB9I,TjZXEhjMq_TdX6h0tJ1d6A

Reacted to "https://excalidraw.com/#json=RFLiIvDMfjJBbWARoJB9I,TjZXEhjMq_TdX6h0tJ1d6A" with ❤️

Reacted to "https://excalidraw.c..." with ❤️

Reacted to "https://excalidraw.com/#json=RFLiIvDMfjJBbWARoJB9I,TjZXEhjMq_TdX6h0tJ1d6A" with ❤️

Yeah we will keep jamming on the collab ideas and post public updates

leanVM is a zkVM so I think you can do general compute fwiw. Agree that currently it is purpose built for xmss which is the signature scheme being used on the CL, but it may not be efficient for the signature schemes being used on the EL

Reacted to "leanVM is a zkVM so I think you can do general compute fwiw. Agree that currently it is purpose built for xmss which is the signature scheme being used on the CL, but it may not be efficient for the signature schemes being used on the EL" with 👍

Reacted to "leanVM is a zkVM so I think you can do general compute fwiw. Agree that currently it is purpose built for xmss which is the signature scheme being used on the CL, but it may not be efficient for the signature schemes being used on the EL" with 👍

A réagi à "leanVM is a zkVM s..." avec 👍

Reacted to "leanVM is a zkVM so I think you can do general compute fwiw. Agree that currently it is purpose built for xmss which is the signature scheme being used on the CL, but it may not be efficient for the signature schemes being used on the EL" with 👍

Reacted to "https://github.com/leanEthereum/leanVM-b for the non-Poseidon version" with ❤️

Replying to "leanVM is a zkVM so ..." Let’s say the zkEVM is “risky”, 8288 could ship just with leanVM too right?

Replying to "leanVM is a zkVM so ..." not a zkEVM though, so wouldn’t be able to compress the frame

Is there time for one misc. question?

Replying to "leanVM is a zkVM so ..." I usually define a zkEVM as “zkVM + program” at least thats the modern definition

Replying to "leanVM is a zkVM so ..." Yep @Luca Donno | L2BEAT but we are looking to make leanVM use RISC-V ISA

can you share the analysis?

Reacted to "Yep @Luca Donno | L2..." with 👀

Replying to "leanVM is a zkVM so ..." but the program for evm is quite complicated?

300k would be great

We opted to do it configurable, but 100k by default

we need benchmarks basically but this is a known issue

Replying to "leanVM is a zkVM so ..." To me the zkEVM is the stateless EVM program that runs on the zkVM. But any program + zkVM could also exist without the native EVM program being available

i dont think people should build alt mempools 😅

Replying to "leanVM is a zkVM so ..." For privacy pools, rollups etc

Reacted to "Yep @Luca Donno | L2BEAT but we are looking to make leanVM use RISC-V ISA" with 🔥

Replying to "https://excalidraw.c..." Hmm this is empty for me

Replying to "i dont think people ..." Agreed, it is a temporary solution to test stuff

Reacted to "Agreed, it is a temporary solution to test stuff" with 👍

it doesn't require other EIPs to adjust a parameter

A réagi à "Agreed, it is a te..." avec 👍

It tries to override your existing diagram so you should accept that

if 100k is exceedingly conservative, 250k + means we can do private tx use cases — how hard would it be to consider that

It wouldn't require and EIP to adjust and can be done stepwise

Replying to "https://excalidraw.c..." Ok I got it to work I think; thanks

Reacted to "if 100k is exceeding..." with 🤝

Replying to "leanVM is a zkVM so ..." Yep agree, was mainly just separating the two concepts. Ie we have the zkVMs: leanVM, SP1, ZisK etc Then we have the thing that they are proving, if this program is the EL STF, then we call it a zkEVM. So leanVM + EL STF = zkEVM and SP1 + EL STF = zkEVM

Reacted to "It wouldn't require and EIP to adjust and can be done stepwise" with 👍

Replying to "leanVM is a zkVM so ..." Its a bit confusing because what we have been calling leanVM so far is the VM + the signature aggregation program

Reacted to "Its a bit confusing because what we have been calling leanVM so far is the VM + the signature aggregation program" with 😁

Reacted to "To me the zkEVM is the stateless EVM program that runs on the zkVM. But any program + zkVM could also exist without the native EVM program being available" with 👍

Replying to "leanVM is a zkVM so ..." TIL

Reacted to "For privacy pools, rollups etc" with 👍

Reacted to "TIL" with 😁

For us 236k is minimum gas required for verification frame for private pool withdrawal

A réagi à "For us 236k is min..." avec 👍

Reacted to "For us 236k is minimum gas required for verification frame for private pool withdrawal" with 🫢

Reacted to "For us 236k is minimum gas required for verification frame for private pool withdrawal" with 👍

Reacted to "For us 236k is minimum gas required for verification frame for private pool withdrawal" with 👍

Reacted to "For us 236k is minimum gas required for verification frame for private pool withdrawal" with 🙏

Realistically 350 is required if we have up to 4 nullifiers

Thanks all!

Reacted to "Realistically 350 is required if we have up to 4 nullifiers" with 👍