Account Unification

[lrettig]

Overview

We propose an account and transaction model that unifies all accounts into a single smart contract-based account type. Under this proposal, unlike Ethereum today, Spacemesh would have no "EOA" (externally owned account) or "simple", keypair-based account (which cannot contain code). This abstracts or encapsulates the logic that allows nodes to verify transactions (e.g., by ensuring that they have valid signatures and nonces) into smart contract logic as part of a special verify method. It means that this verification logic, like all smart contract execution logic, runs in the VM and may in theory be arbitrarily complex (although in practice it will be subject to certain restrictions to prevent denial of service and griefing attacks, and will be optimized).

We introduce a subclass of account known as a "Principal" account, so-called because it's able to act as a principal, or source of funds, in a transaction. (The user who generates, signs, and broadcasts the transaction acts as its agent.) The only difference between a Principal and non-Principal account is that a Principal account implements the verify method that is executed to verify transactions sent on its behalf, and is thus allowed to act as a source of funds, while a non-Principal account implements no such method and is forbidden from acting as a source of funds. (Equivalently, all accounts can be thought of as Principal accounts, but those that don't explicitly implement verify() instead have an implicit implementation that always returns false and may therefore never be used as a source of funds.)

EOAs are replaced by a "personal wallet" smart contract template with simple, cheap, sanctioned verification logic that is effectively identical to the existing verification logic.

For background reading, please see:

• research forum thread and tag
• Account abstraction (single account type) product#86
• EIP-2938 for the most recent, mature, and complete proposal (in particular, the Rationale section)
• EIP-2938 Account Abstraction Explained
• Account Abstraction Beyond EIP-2938
• Account Abstraction
• Account Abstraction (EIP-2938): Why & What
• Implementing account abstraction as part of eth1.x - EIPs - Fellowship of Ethereum Magicians

Goals and motivation

• simplicity and elegance: having only a single account type makes the core code simpler and makes it easier to reason about the protocol
• more flexibility in how transactions are funded. Rather than every transaction needing to be funded from an EOA, a smart contract can self-fund transactions that target it. Think of a multisig where the fees for transactions that move things into and out of the multisig are funded by the multisig itself, or an application such as a decentralized exchange that pays gas fees for its users. This also leads to...
• better privacy, since it breaks the link between transaction sender and source of funds. It fixes the catch-22 that currently requires users to acquire coins in order to move coins out of a mixer or privacy tool such as tornado.cash.
• Users are not bound by a single, sanctioned transaction verification scheme and are free to experiment with whichever signature scheme (Scnorr, BLS, post-quantum, etc.) or other transaction verification method they like: single sig, multisig, social recovery, etc. Note that this extends to replay protection and nonce verification too: different principal accounts may choose to implement different classes of replay protection, or even to omit it entirely.
• It’s easier to prune certain classes of “failed” transactions–i.e., those that fail arbitrary validation checks (e.g., involving transaction ordering)

Tradeoffs/downsides/challenges

• Makes mempool management harder for miners. It’s harder for a miner to determine whether a transaction will pay any gas (mitigated by certain constraints).
• There is a potential DoS attack vector if “spam” transactions can be generated that require a lot of verification work without paying gas (in practice, it must not be possible to generate transactions that require significantly more work than validating the signature on a “simple” tx requires now)
• In order to prevent replay attacks (and maintain the uniqueness constraint on txids), the nonce of a Principal contract must never be reset to zero, even if the deployed smart contract is self-destructed
• The multi-tenant use case (e.g., a DEX or a multisig shared by many users) is tricky because one transaction can invalidate multiple pending transactions with the same target (by, e.g., increasing the nonce). There are potential workarounds including nonce malleability.

High-level design

• the protocol implements a single account model. An account is a data structure consisting of the following: address -> [code, balance].
• the sender field of a transaction is replaced by a principal field. All transactions contain this field, and it must never be nil (with the possible exceptions of coinbase and reward transactions). The principal is the account whose balance is debited for gas fees and sends (inside or outside the VM). If the principal of a transaction is not set, or is set to the address of an account that is not a Principal account, or if the transaction nonce does not match the Principal account's nonce, that transaction is invalid. If the balance of the Principal account is not sufficient to pay gas and cover all funds transfers contained in the transaction, the transaction fails.
• all accounts whose code implements the verify() method are considered Principal accounts.
• there are certain restrictions on which state verify() can read and write. See "State management", below, for more.
• funds may be sent to an account that does not yet exist (as in Ethereum). When this happens, the account is spontaneously created and its balance is updated (but its code remains unset). A smart contract may later be deployed at this address, in which case it "inherits" the pre-existing balance. (This allows a user to receive funds into a Principal account "counterfactually", as if the account code were already there, and only requires the user to deploy the account code when they need to transfer or spend the funds.) Note that a Principal account may not serve as a source of funds for any transaction, including deploying code to the account itself, until after that code has been deployed.
• in order to faithfully replicate EOA behavior, whereby a user can immediately spend funds accumulated into such an account "counterfactually" without needing an external source of funds, we allow a special self-funded spawn transaction. When a Spawn transaction specifies a template address, no principal, and the destination account contains funds, verifydata is passed into the template's verify() method, and if it returns true, the template is spawned to destination and destination pays gas for the spawn operation.
• when a node receives a new transaction, it performs the following checks, in order, to determine whether the transaction is valid:
  1. ensure that the transaction is syntactically valid and that all required fields (principal, destination, amount, calldata, verifydata) are set
  2. ensure that the principal field is set to the address of a Principal account (i.e., that this account implements the verify() method) and that the account contains enough gas to verify the transaction
  3. call the verify() method of the referenced Principal account, passing in the transaction verifydata. Ensure that, within MAXVERIFYGAS gas usage, the method either returns true or else calls a PAYGAS opcode, and that it does not read or modify state that is not Protected (it may only read its own state, not state from any other account). If the account balance is insufficient to cover the gas spent when PAYGAS is called, the transaction is invalidated.
  4. if verify() ultimately returns true, the transaction is verified, and if it returns false, the transaction is invalidated.
• after verification, for transactions with calldata, the destination smart contract is called with calldata (as in Ethereum today). Note that destination may or may not be be the same as principal.

Prior art

• EIP-2938: Account Abstraction
• EIP-3074: AUTH and AUTHCALL opcodes

Proposed implementation

• modify transaction and account data model along the lines described above
• add the required opcodes (PAYGAS) to SVM
• modify SVM to pass verifydata to a Principal account's verify() method and enforce the constraints described above
• write a generic, efficient, sanctioned Principal smart contract "Simple wallet" template that can be used to mimic the behavior of an EOA (one keypair, one signer, sequential integer nonce, no logic other than transaction verification). The smart contract should run in SVM, but may offload heavy logic, such as signature verification, to the native client code as a "precompile." This template should be deployed at genesis or shortly thereafter, and will be the only available, sanctioned wallet template in the beginning.

Transaction format

The specifics of transaction format are outside the scope of this proposal (see #23, #37). However, Account Unification requires that transactions contain at least the following fields:

• principal (address) // pays the gas fees and source of funds for value, must not be nil (except for self-funded spawn)
• destination (Address) // receiver of funds and destination smart contract for method calls (with calldata)
• amount (Amount) // coin value to be transferred to destination
• calldata (binary) // optional - smart contract method execution call data: method selector, call values
• verifydata (binary) // passed to verify(), must not be nil. Typically contains a signature and a nonce.

State management and transaction ordering

An important invariant in both Spacemesh 0.1 and Ethereum is that no transaction that originates from sender A can invalidate a transaction from sender B (where A != B). This is due to the fact that a transaction can only be invalidated if the sender account balance is too low to pay the gas, or if the sender nonce doesn't match, and an account's balance can only decrease, and its nonce can only change, as a result of a transaction from the same account. Without this invariant, mempool management and transaction selection become much harder because transactions are more order-dependent: processing any transaction from any sender could invalidate any other transaction from any sender.

If we allow verify() to implement arbitrary logic, maintaining this invariant becomes much harder. We propose to start with restrictions on verify() in an initial phase and relax them somewhat in a later phase, pending further research.

Phase I: Stateless verify

In the first phase, verify() must be totally stateless. It may only read immutable state such as storage items set when the principal contract was initially deployed. It must not read state from any other contract (since the existence or non-existence of such state is possibly mutable).

Certain opcodes that read external state, such as BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT, BALANCE, and those that perform external call/create/state access (CALL , CALLCODE, STATICCALL, CREATE, CREATE2, EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) are also disallowed.

Phase II: Limited access to state

Pending further research, in future it should be possible to relax the restrictions on verify() somewhat, along the following lines:

Level one vs. level two state

In order to verify a transaction with a given principal, a node must already read the principal account data from the trie, including its code and balance. If we think of this account data as occupying a single "page" of memory, for some fixed page size, then the additional work associated with reading a small amount of "level one" storage is negligible. Intuitively we can think of this "level one" storage as consisting of a small number of 256-bit storage values: enough to store a few signatures (for a multisig), a nonce, and possibly a per-signature daily spending key.

Under this scheme, verify() may read and write this level one state for its own account but may not read or write any other state.

Protected state

Under this scheme, the account storage of a Principal account is divided into two sections: Protected and Unprotected. Unprotected state may be read and modified by any method other than verify(). Protected state may only be modified by the verify() method, and the verify() method may only read Protected state. (Any method may read, but not write, Protected state.)

Note that we may decide to combine level one state and protected state.

Slow reads and writes

We introduce new opcodes for "slow" read and write of account storage. A slow write only takes effect at the next state checkpoint: typically, the following layer. A slow read returns the value as of the last checkpoint: typically, as of the previous layer. Under this scheme, verify() may perform slow reads and writes only, since they can never invalidate other transactions before the next checkpoint.

Questions

• How do we enable multi-tenancy: where many agents can transact using the same Principal account? The challenge here is that we can no longer use sequential nonces since, if nonces need to be sequential, then one agent's transaction may invalidate those of many other agents. Without sequential nonces, how do we allow transaction batching, replace by fee, or child pays for parent (CPFP)?
• Does the proposed "parked" or "lower bound" conservative balance design proposed by research and used in transaction selection, and needed to prevent conflicting transaction spam, still work in this model? In particular, is it compatible with a non-stateless verify() method that can read and write state, even state that's protected? (Cheaply calculating conservative balances requires being able to verify transactions in a fashion that is not order-dependent. Any version of AU that is not purely stateless results in transactions whose validity is, at least partially, order-dependent. Sequential nonces help somewhat but not entirely since it's trivial to compute a "matrix" of multiple transactions per nonce such that pathfinding through that matrix is computationally infeasible.)
• Do we want to allow an account to pre-fund a deploy transaction as well, before the account code has been deployed? We could add an exception case for this (at the cost of some simplicity). How to handle self-funded spawn of a wallet account? We need this in order to, e.g., allow users to spend rewards they've accumulated?

A: yes, see the description of self-funded spawn, above

• What should MAXVERIFYGAS be set to?
• How can this model be made compatible with our "ED++" signature scheme (where the principal of a transaction is implicit via signature extraction rather than explicit)?
• How expensive is it to run verify() inside the VM to verify transactions rather than doing so entirely in native code? Note that the signature check operation itself can still be implemented natively (and called from inside the VM as a "precompile" host function). The cost associated with doing so involves context switching into and out of the VM.
• As a concrete case study, how can our vault design, especially features that rely on state such as daily per-user spending limits, work with this design?
• What's the signature of verify()? In particular, can it return or pass data into the "main" contract code to, e.g., indicate which signatures were verified in a multisig/vault?
• How are account addresses determined? Do we want two methods like Ethereum's CREATE and CREATE2?

A: we want both. CREATE will set the account address based solely on spawning transaction principal account and nonce. CREATE2 will instead use principal account, salt, and init code (see EIP-1014). This is orthogonal to Account Unification.

Dependencies and interactions

• SVM
• state processing
• account, transaction data models
• mining, transaction selection and validation

Implementation plan

• benchmarking and performance testing
• rewrite the account model along the lines described
• rewrite native transaction verification as described
• introduce the necessary SVM opcodes as described
• update SVM to handle verifydata, find and run verify(), and disallow reading/writing of dynamic state as described
• write the basic, default single-tenant principal wallet smart contract
• update the vault contract design to work with AU

Stakeholders and reviewers

• @YaronWittenstein
• @noamnelke
• @lrettig

Testing and performance

tbd

[countvonzero]

We introduce a subclass of account known as...

this doused my fire quite a bit. what you said later simplicity and elegance rings the most true to me. i wonder if we can lose the distinction by enforcing the account creator to decide whether verify() returns true/false. i.e. make verify() mandatory and forces the creator to explicitly decide if this account is to be a fee-paying account.

Unprotected state may be read and updated by any method. Protected state ...

i am confused by the wordings here. do you mean
Unprotected state may be read and updated by any method but verify()?

opcodes that read external state, such as …, are also considered Unprotected state

maybe i am looking at this from the wrong perspective, i found the word unprotected counter intuitive here. it seems if verify() should not call these opcodes, they are protected... what do you think of using safe/unsafe. i.e. verify() can read/write safe state.

If the account balance is insufficient to cover the gas spent when PAYGAS is called, the transaction is invalidated.

assuming the order of execution is below:

----------------------------> PAYGAS ---------------------------->
   verification phase                          execution phase

under this proposal, it's unclear to me whether we charge any gas for verification phase. the wording here seems to imply yes. if that's true, it makes the name PAYGAS a little awkward, because one already pays gas before PAYGAS is reached. in this case, i think we should use a different name for the opcode, say VERIFIED, and it serves as a checkpoint. that way, we can just send SVM the calldata after VERIFIED if we decide to run verify() outside SVM. i recall in the case of ED++, the public key extraction (required outside SVM) has essentially done the job for verify() and therefore can be skipped for optimization.

the Ethereum proposal was that no gas paid until it reaches PAYGAS opcode. and if the execution during the verification phase exceeds the cap, the transaction is considered invalid.

if we are not charging gas for the verification phase, then i misunderstand your words. tho i actually like the idea of paying gas for the verification phase after the signature verifies. however small, it deters the DoS attack. since we are potentially instantiating a SVM for verify(), the cost of being spammed doesn't seem negligible to me.

possible exceptions of coinbase and reward transactions

i had assumed that rewards (mining or otherwise) will be done via internal transfer instead of official transactions

[lrettig]

i wonder if we can lose the distinction by enforcing the account creator to decide whether verify() returns true/false. i.e. make verify() mandatory and forces the creator to explicitly decide if this account is to be a fee-paying account.

I don't understand what you mean. The way we verify a transaction is by passing its verifydata to the verify() method of a Principal account. If the method returns true (and the gas and state rules aren't violated), the transaction is verified/validated. If it returns false, the transaction is invalidated. I think allowing smart contracts to implement this method or not, and allowing those that do implement it to act as Principals, is about as simple and elegant as we can get here, but of course I'm open to alternative ideas!

Unprotected state may be read and updated by any method. Protected state ...

i am confused by the wordings here. do you mean
Unprotected state may be read and updated by any method but verify()?

Yes, you're right, I fixed this.

opcodes that read external state, such as …, are also considered Unprotected state

maybe i am looking at this from the wrong perspective, i found the word unprotected counter intuitive here. it seems if verify() should not call these opcodes, they are protected... what do you think of using safe/unsafe. i.e. verify() can read/write safe state.

The way I think about it, "protected" means "may only be set inside verify()."

under this proposal, it's unclear to me whether we charge any gas for verification phase. the wording here seems to imply yes... the Ethereum proposal was that no gas paid until it reaches PAYGAS opcode. and if the execution during the verification phase exceeds the cap, the transaction is considered invalid.

This is a bit counterintuitive, but by definition you cannot charge gas before PAYGAS because you haven't yet established the validity of the transaction in question, and invalid transactions by definition cannot pay gas. This is no different than how things work in Ethereum 1 or Spacemesh v0.1: if a simple transaction has an invalid signature, you still need to perform some computation in order to establish the validity, and if the signature is invalid, no one pays any gas for this computation.

I don't see a reason to deviate from the EIP-2938 design here:

The opcode works as follows. If all three of the following conditions (in addition to the version number check above) are satisfied:

The account’s balance is >= gas_price * gas_limit
globals.transaction_fee_paid == False
We are in a top-level AA execution frame (ie. if the currently running EVM execution exits or reverts, the EVM execution of the entire transaction is finished)
Then do the following:

Subtract gas_price * gas_limit from the contract’s balance
Set globals.transaction_fee_paid to True
Set globals.gas_price to gas_price, and globals.gas_limit to gas_limit
Set the remaining gas in the current execution context to equal gas_limit minus the gas that was already consumed
If any of the above three conditions are not satisfied, throw an exception.

At the end of execution of an AA transaction, it is mandatory that globals.transaction_fee_paid == True; if it is not, then the transaction is invalid. At the end of execution, the contract is refunded globals.gas_price * remaining_gas for any remaining gas, and (globals.gas_limit - remaining_gas) * globals.gas_price is transferred to the miner.

PAYGAS also serves as an EVM execution checkpoint: if the top-level execution frame reverts after PAYGAS has been called, then the execution only reverts up to the point right after PAYGAS was called, and exits there. In that case, the contract receives no refund, and globals.gas_limit * globals.gas_price is transferred to the miner.

possible exceptions of coinbase and reward transactions

i had assumed that rewards (mining or otherwise) will be done via internal transfer instead of official transactions

We haven't finalized this design yet. That's why I said "possible" exception :)

[countvonzero]

I don't understand what you mean. The way we verify a transaction is by passing its verifydata to the verify() method of a Principal account. If the method returns true (and the gas and state rules aren't violated), the transaction is verified/validated. If it returns false, the transaction is invalidated. I think allowing smart contracts to implement this method or not, and allowing those that do implement it to act as Principals, is about as simple and elegant as we can get here, but of course I'm open to alternative ideas!

like we discussed during the R&D meeting, my end goal is uniform treatment in code and in future design. whether an account has verify()/nonce can be "compressed away" like Tal said, but they will appear homogeneous to devs/users.

This is a bit counterintuitive, but by definition you cannot charge gas before PAYGAS because you haven't yet established the validity of the transaction in question, and invalid transactions by definition cannot pay gas.

what threw me off was this sentence

If the account balance is insufficient to cover the gas spent when PAYGAS is called, the transaction is invalidated.

since gas spent when PAYGAS is called is supposed to be zero. so i had mistaken you to mean that we want to charge gas before PAYGAS. but what you really meant was we are going to charge the max gas upfront as soon as we hit PAYGAS, and then do refund later if necessary. just like the EIP.

[avive]

Q: regarding principal - let's consider this use case: Alice wants to transfer funds to Bob via an app that pays gas. You mentioned that the principal both pays gas and is the source of funds in the proposed design - so how is this use case going to be handled, or are we saying that Alice can't be the source of funds in a transaction where she's not the principal and only an agent? Another example - in a 2/3 vault which pays gas for its users, alice wants to move coin from her account to the vault...

[avive]

Q: I don't fully understand how the invariant discussed in verification can hold in this use case: both Alice and Bob send a transaction around the same time to the same app (e.g. a vault) to spend all of its coins, each transaction with a different payee. Only one of these transaction will executed and the other will throw an insufficient funds runtime exception. There's no way to validate these transactions without knowing the execution order of the STF and actually trying to execute these transactions in the agreed upon order. I think this is a simpler example than what Tal mentioned. I'm also not sure how the idea of parked balance is going to help in the use case I mentioned.

What tal proposes regarding only allowing 1 transaction to a smart contract that can reduce its balance, is quite problematic from usability perspective - popular smart contracts are going to be used frequently by many users, potentially hundreds or thousands of them around the same time. Also, smart contact methods may fail for different reasons based on execution order besides just contract coin balance going to 0. For example, contracts managing tokens, assets, etc... So it should not be about the benchmarks because we don't intend devs to implement Edwards point math in svm code. The benchmarks discussed should be the performance of the EC and crypto precompiled - our provided libs vs. native code.

[avive]

Q: what are concrete examples of verify() needing to write state? What use cases are not possible if verify() can not write state?

[avive]

Regarding iddo's 1st argument - in theory, signature checks via SVM should not be much more expensive because the actual computational work is going to be done in context library functions which should be implemented natively - so as long as a developer writes verify() that uses ed25519 scheme (or any other signature scheme we provide support to) there is no issue and the overhead is not in the core elliptical curve ops and should not be significant. As a bonus, with a tight gas limit on verify(), developers will not be able to implement signature verification which is not done efficiently by a core library at all. I think it is safe to assume that we are going to provide primitive hashing and signature scheme libs as svm libs which are optimized and native. We need to do so to make the svm development platform competitive. So tl;dr - you can't implement your own elliptical-curve math ops in verify() because you will go over the verify() gas limit but you can use our svm crypto libs for custom signature schemes. We can also add additional crypto libs to svm core via soft-forks with additional EC functions.

Regarding tal's argument about DoS using a smart contract that doesn't use a precompiles - the MAX_GAS on verify() addresses this attack scenario. It is not about pre-compiled contracts we approve, it is about providing a smart-contract EC and crypto libs which are natively compiled that developers use which are part of the runtime. For example, see the eth precompiles. Devs use these as building blocks for custom verification but can't implement EC low-level math in smart contracts. As a reference, here's a list of the precompiled eth methods - they are all computational extensive lib functions related to EC and crypto primitives. https://github.com/ethereum/go-ethereum/blob/bd6879ac518431174a490ba42f7e6e822dcb3ee1/core/vm/contracts.go#L51

[avive]

Regarding the idea to limit transactions per layer to a same contract - I don't like this idea. I think it is better the optimistically assume that some of them will work and just execute them in our pre-defined tx sorting order. There are going to be very popular smart contracts and limiting throughput to a small number of txs per layer is very problematic from the user experience perspective. I think there is no way good way around the issue that you can't tell whether a smart contract transaction is 'valid' without executing all the transactions to the contract in a layer and that we should work under this assumption. I think this is inherent to the state-full smart contracts computation model. The assumptions that this can be done needs to be revisited.

[avive]

A note regarding the discussion about state changes and transactions - there is no need for transactions which do not modify state - for this there's an API that reads apps and account state and we can assume there will always be at least one free open api endpoint over the Internet. Smapp will allow to read any app state w/o transactions as well via remote public or local node api. Explorer will also show app state for each spawned app. No rational user will submit a transaction that is not intended to change state as it costs money and reading the state is free.

[lrettig]

are we saying that Alice can't be the source of funds in a transaction where she's not the principal and only an agent?

The idea here is that "Alice" is a person, not an account. In the terminology of this proposal, she's an "agent," and agents don't have funds, only principals do (agents have private keys that let them sign transactions). Alice stores her funds in a "wallet" which is really a principal account under the hood. If she wants to send funds from this wallet to Bob, she creates, signs, and broadcasts a transaction with the wallet address set as the principal (and Bob's address in the calldata).

Alice wants to transfer funds to Bob via an app that pays gas

Let me rephrase your question: Alice wants to send funds contained in her private (1-of-1) wallet but she wants a different app to pay the fees for the transaction. This is an interesting question. I think this sort of use case is a tiny corner case, that in practice it is not at all common, and that we're probably better off not trying to support this in the beginning. I have to give some thought to whether allowing two sources of funds in a single transaction is secure.

Here's one pattern that would work within the proposed framework: Alice grants the app in question permission to spend funds contained in her private wallet. (The permission could be time- or amount-limited, or there could be a whitelisted set of destination addresses, etc.). Then she can submit a transaction to the app, and let the app pay, and the app could call the wallet as a delegate and send the funds to Bob on her behalf.

in a 2/3 vault which pays gas for its users, alice wants to move coin from her account to the vault...

Assuming by "her account" you mean the sort of private wallet I described above, then the same pattern should work: Alice would first have to delegate authority to the vault to move funds from her private wallet, then the vault could do this on her behalf and pay the fees. This pattern is very similar to how ERC-20 works today.

[lrettig]

I'm also not sure how the idea of parked balance is going to help in the use case I mentioned.

In the simplest, and most extreme, case, when one of these transactions is processed, the miner/validator immediately sets the parked balance of the app account to zero (at least until the following layer when all pending transactions have been processed). Then all other transactions with the same principal would be dropped, or at least would be held in "stasis" and not put into blocks in the same layer. The goal here is to avoid multiple conflicting transactions actually being included in the same layer. This is precisely the same with simple transactions as it is with account unification: if a miner sees a tx that empties an account's balance completely, it should drop or hold all other transactions from that account.

What tal proposes regarding only allowing 1 transaction to a smart contract that can reduce its balance, is quite problematic from usability perspective - popular smart contracts are going to be used frequently by many users, potentially hundreds or thousands of them around the same time.

Agree

we don't intend devs to implement Edwards point math in svm code. The benchmarks discussed should be the performance of the EC and crypto precompiled - our provided libs vs. native code.

Agree, this is what precompiles are for. But Wasm is really performant and, if the performance is pretty close, it might make sense to actually perform these checks inside the VM.

[lrettig]

Q: what are concrete examples of verify() needing to write state? What use cases are not possible if verify() can not write state?

We discussed an example on the call: a vault (multisig) with a per-user daily spending limit, or a vault where we want to be able to change the signatories/keys. If verify() couldn't read state, any valid user could drain all the funds in the vault by sending lots of transactions. In general, any use case that needs to be able to invalidate a transaction (before it pays any gas at all) in a state-dependent fashion wouldn't be possible. I'm sure we could think of other examples.

Here's another: a decentralized exchange which charges zero gas if you submit a tx but the price has already moved too far.

[lrettig]

there is no need for transactions which do not modify state

The question isn't about transactions with don't modify state, it's about reading and writing state inside verify() specifically.