@alex-forshtat-tbk - on revocation - I don’t think it needs to be a new concept in 7730.
Descriptor is just data. Trust comes from attestation. In 8176 revocation is an on-chain EAS revocation. A wallet on attestation-gated policy sees no valid attestation, refuses to clear-sign.
Hello @llbartekll, and than you for your response. I have thought about it some more and I still think that “no valid attestation, refuses to clear-sign” is not always sufficient. This implies there are only two states the wallet may be in with regards to ERC-7730: “valid specification” and “no valid specification”.
I think we should consider adding a third state - “removed - malicious” - when the contract that was previously in the registry is hacked. I think that for many years it will be extremely common for users to fall back to blind signing until ERC-7730 covers almost all contracts they interact with. Before that happens, simply removing a contract from the registry seems like an inadequate mitigation. The registry probably should not be spammed with all drainer contracts out there, but those being revoked probably should carry a warning.
I have created a number of PRs for some of the ideas specified in the previous post by the way, will be grateful for any kind of feedback or review:
As for the storage layout support for “Transaction Outcome Simulation” and “Transaction Outcome Assertions”, this is proving to be a big issue. If anyone is interested in collaborating on this idea that would be great. Here is the early draft of the progress so far:
Regarding @mike-diamond 's work on ERC-8265, a “Transaction Envelope” sound like something that will be critically needed for the Transaction Outcome Simulation" / “Transaction Outcome Assertions” support. I will be happy to stay in touch!
Support for ERC-7730 clear signing has been landed today in micro-eth-signer (GitHub - paulmillr/micro-eth-signer: Minimal library for Ethereum transactions, addresses and smart contracts. · GitHub). micro-eth-signer is smaller (js) alternative to ethers / viem.
I am glad to see people actually thinking about this problem! Unfortunately, I don’t think this actually solves the problem fully enough to be useful. The DSL is half of the problem, but how the signer gets the DSL in a trustless, permissionless, and censorship resistant way is the other half of the problem that this EIP describes as out of scope.
Without solving the hard problem of how the user gets the DSL to the signer, you are left with a nice DSL that isn’t actually useful in a high security context. At best, signer vendors will hard-code in the top 10 most popular dapp DSLs at the time of feature launch and maybe add one more app every year or so. It is just way too much work for them to maintain a curated database of DSLs for every app on Ethereum.
Centralized registries and signed payloads are just honeypots for attackers to compromise and scam users on a massive scale.
The solutions proposed in Trustless Signing UI Protocol · Issue #719 · ethereum/EIPs · GitHub and https://ethresear.ch/t/enforceable-human-readable-transactions-how-to-solve-bybit-like-hacks/21836 (these are competing solutions) directly address these concerns, and the former also addresses localization, multiple presentation formats, etc.
I completely agree with the authors that this is a major problem, and we definitely need to solve it. We just need to actually finish the solution and not leave it in a centralized-friendly half-finished state like this EIP is currently in.
Hi all,
related to the discussion above about batching/composability, I have a narrower question about value-bearing dynamic arrays in ERC-7730 descriptors that I would like to illustrate on an example.
Consider a batch payment contract function that accepts an array of payment structs:
struct Payment {
address asset;
address recipient;
uint256 amount;
bool debitSigner;
}
The contract executes all payments in order. For every entry where debitSigner == true, the contract may consume amount of asset from the signer. Entries where debitSigner == false use assets already held by the contract or received through previous payments.
I understand that ERC-7730 supports array iteration, so a simple case like Deposit { token; amount }[] can be represented by iterating and showing every amount.
The harder case is when not every array entry is a user-funded debit. Showing all payments.[].amount may be noisy or misleading because some entries are internally funded payments. But showing a fixed field like payments.[0].amount is unsafe, because the user-funded amount may be spread across multiple entries, possibly with different assets.
What we would want semantically is closer to:
for each payment where debitSigner == true:
show amount formatted with asset
Any ideas on how similar calldata could to be handled?