smstack.eth

@akashneelesh Can I know the name of the PQ safe wallet or where can I use it?

native account abstraction since 2021 also what if i told u we have a post quantum wallet on starknet already ?

@GiulioRebuffo @ch4r10t33r @ryanberckmans @ben_a_adams Doesn't 8141 tx type support blob?

@ch4r10t33r @ryanberckmans @ben_a_adams @StackDigest It cannot even do blobs or any meaningful AA change without protocol change????

Since people have been debating Frame Transactions, I decided to make my own proposal alongside @ben_a_adams ethereum-magicians.org/t/frame-transa… Here, I argue that Frame Txs in their current state offer only the illusion of abstraction and are/always going be moat, at least regarding the verification. On top of it, they are really bad at solving PQ unlike people claim they do (have been working on PQ last 2 weeks). OTOH Schemed Transactions (which is what is being introduced) are a reduced version of Tempo Transactions, they leave room to rethink frames later and enshrine what are today the "Verify" frames. With schemed transactions, we might not only get a way to enshrine good login into Ethereum but also immediatelly do PQ, all inside of Hegota with 1/10 of the complexity of Frame Txs.

So true, even watching these discussions are so tired... from 3074, 7702, and now 8141

You can build whatever you want, even games. ethereum.org/gaming

@howydev Gotcha fully understood, agreed that it would not be a huge blocker!

@StackDigest Yup, but it’s not a big lift to fork + remove that check. The purpose is anti footgun, similar vibe as to check if transfer recipient is address(0)

So clearly designed only for Tempo?

@howydev But isn’t it blocking to open the channel here, unless I misunderstand it? #L68" target="_blank" rel="nofollow noopener">github.com/tempoxyz/tempo…

@StackDigest isTIP20 is mostly just a guardrail, full functionality is possible even without it!

@donnoh_eth lol banger

I've never understood the argument that Ethereum focusing on these cypherpunk-style values is somehow anathema to stablecoins, DeFi, or other financial applications. Ethereum is the clear leader in all of those activities because it offers censorship-resistance (aka access), transparency (aka verifiability), and security (aka property rights). If you study the long history of financial services, the markets and systems that attract the most participants and capital do so because they are widely accessible yet protective of everyone's rights. In TradFi this is done via laws and regulations. In crypto we can do it with cryptography and incentives. The chains that sell out (or simp out) on these values because of a hack (or because some suit-wearing bank exec who is simultaneously lobbying to kill crypto asked them to) will never succeed with stablecoins, tokenization, or DeFi. Those chains are even worst than the TradFi alternative. Off-chain or on, the most reliable financial infrastructure is the one that's least likely to screw you. A Foundation that focuses on pithy marketing slogans or throws money at every bank doing innovation theater provides zero assurances to future users that they won't get screwed. A Foundation that embraces a philosophy like CROPS does. Kudos to the EF for sticking to what matters, in markets and beyond.

Due to EIP-8141 (native AA), I've been deeply engaging with the ACD process, and there's some truth to what Dankrad is saying in that it feels like the people with decision making powers -- the client devs -- are somewhat detached from real-world usage of Ethereum. However, I found that it's not that those people don't care -- it's just that their day-to-day job as client devs simply don't provide them with the opportunities to interact with application-layer builders and end users as much as, say, someone like me whose job is to build and sell commercial solutions do. So how do we bridge the gap between 1) Ethereum's major decisions are made by client devs, and 2) client devs don't get to learn much from application builders and users? That's the key question the EF has to solve. On the other hand, I also feel that application-layer builders need to take matters into their own hands more. You can criticize the ACD process all your want, but it IS open. All the meetings are announced in advance (github.com/ethereum/pm/is…), free for all to join, and recorded for all to watch. When you do engage with the process, like I've been for the past month for native AA, you find that the client devs DO LISTEN. They are not crazy people with evil agendas -- they just don't know what they don't know, just like the rest of us. So yes, EF should keep improving the process, but before you complain about Ethereum heading in the wrong direction, ask yourself if you have ever TRIED to engage. Ethereum is for all of us and we all share responsibilities for making it better.

You mean how to make an account to be fully PQ without deployment, right? I think this needs a change on default code behavior of 8141; adding PQ sig verification support on the flow. But not sure it's a right approach, since basically the end goal of EIP-8141 seems to be removing the signature / tx types out of the protocol. Changing protocol at every time we need a new signature scheme does not fit for the flexibility of EIP-8141 - if so we can just take Tempo tx approach I guess.

Ty for sharing this experimental PoC!! Qq: In the case of “Pattern 3: P-256 (Passkey) Signing,” the account is still attached to an EOA, so it’s not really a PQ solution. Is there any case where the account can be fully P256 without deployment? Since you already solved VERIFY by calling the precompile directly. WDYT?

Mirae Asset, 'Korean BlackRock' managing around $1T assets in Korea, published a report whose title is 'This year belongs to Ethereum'. And there's a very interesting pharagraph... "The institutional gold standard is the Stage 2 Rollup. Within the six-tier risk matrix, only Stage 2 Rollups meet the minimum trust requirements necessary for institutional capital. And because Stage 2 Rollups inherit 100% of Ethereum L1’s security, institutional capital will inevitably flow into the Ethereum ecosystem." Long live Stage 2 L2s securities.miraeasset.com/bbs/download/2…

@Ayussheth @claudeai I’m willing to, please ship this @claudeai

new @claudeai feature: watch ads to reset or extend your weekly limit.

The ERC20 paymaster case is great, but there are two issues that may prevent it from working in the initial version of frame txs. First, the paymaster contract needs to read price data from an external DEX during the VERIFY frame to determine whether the RAI amount in the following frame is sufficient. Without a staking-based rule like ERC-7562, this external call would be rejected at the mempool level. Since the staking-based rule is unlikely to be part of the initial rollout given the conservative mempool stance you mentioned, this use case may have to wait. Second, there's currently no mechanism to track cumulative gas usage across all frames, which makes accurate refunds impossible. Using maxCost from the TXPARAM opcode is a workaround, but it would cause users to overpay. A cleaner solution would be to extend TXPARAM to return gas_used for a given frame index. Since execution clients need to track per-frame gas usage to process frame txs correctly when implementing EIP-8141, this extension wouldn't add meaningful complexity. More details here: hackmd.io/b83foGSVQpWRV3…

Now, account abstraction. We have been talking about account abstraction ever since early 2016, see the original EIP-86: github.com/ethereum/EIPs/… Now, we finally have EIP-8141 ( eips.ethereum.org/EIPS/eip-8141 ), an omnibus that wraps up and solves every remaining problem that AA was intended to address (plus more). Let's talk again about what it does. The concept, "Frame Transactions", is about as simple as you can get while still being highly general purpose. A transaction is N calls, which can read each other's calldata, and which have the ability to authorize a sender and authorize a gas payer. At the protocol layer, *that's it*. Now, let's see how to use it. First, a "normal transaction from a normal account" (eg. a multisig, or an account with changeable keys, or with a quantum-resistant signature scheme). This would have two frames: * Validation (check the signature, and return using the ACCEPT opcode with flags set to signal approval of sender and of gas payment) * Execution You could have multiple execution frames, atomic operations (eg. approve then spend) become trivial now. If the account does not exist yet, then you prepend another frame, "Deployment", which calls a proxy to create the contract (EIP-7997 ethereum-magicians.org/t/eip-7997-det… is good for this, as it would also let the contract address reliably be consistent across chains). Now, suppose you want to pay gas in RAI. You use a paymaster contract, which is a special-purpose onchain DEX that provides the ETH in real time. The tx frames are: * Deployment [if needed] * Validation (ACCEPT approves sender only, not gas payment) * Paymaster validation (paymaster checks that the immediate next op sends enough RAI to the paymaster and that the final op exists) * Send RAI to the paymaster * Execution [can be multiple] * Paymaster refunds unused RAI, and converts to ETH Basically the same thing that is done in existing sponsored transactions mechanisms, but with no intermediaries required (!!!!). Intermediary minimization is a core principle of non-ugly cypherpunk ethereum: maximize what you can do even if all the world's infrastructure except the ethereum chain itself goes down. Now, privacy protocols. Two strategies here. First, we can have a paymaster contract, which checks for a valid ZK-SNARK and pays for gas if it sees one. Second, we could add 2D nonces (see docs.erc4337.io/core-standards… ), which allow an individual account to function as a privacy protocol, and receive txs in parallel from many users. Basically, the mechanism is extremely flexible, and solves for all the use cases. But is it safe? At the onchain level, yes, obviously so: a tx is only valid to include if it contains a validation frame that returns ACCEPT with the flag to pay gas. The more challenging question is at the mempool level. If a tx contains a first frame which calls into 10000 accounts and rejects if any of them have different values, this cannot be broadcasted safely. But all of the examples above can. There is a similar notion here to "standard transactions" in bitcoin, where the chain itself only enforces a very limited set of rules, but there are more rules at the mempool layer. There are specific rulesets (eg. "validation frame must come before execution frames, and cannot call out to outside contracts") that are known to be safe, but are limited. For paymasters, there has been deep thought about a staking mechanism to limit DoS attacks in a very general-purpose way. Realistically, when 8141 is rolled out, the mempool rules will be very conservative, and there will be a second optional more aggressive mempool. The former will expand over time. For privacy protocol users, this means that we can completely remove "public broadcasters" that are the source of massive UX pain in railgun/PP/TC, and replace them with a general-purpose public mempool. For quantum-resistant signatures, we also have to solve one more problem: efficiency. Here's are posts about the ideas we have for that: firefly.social/post/lens/1gfe… firefly.social/post/x/2027405… AA is also highly complementary with FOCIL: FOCIL ensures rapid inclusion guarantees for transactions, and AA ensures that all of the more complex operations people want to make actually can be made directly as first-class transactions. Another interesting topic is EOA compatibility in 8141. This is being discussed, in principle it is possible, so all accounts incl existing ones can be put into the same framework and gain the ability to do batch operations, transaction sponsorship, etc, all as first-class transactions that fully benefit from FOCIL. Finally, after over a decade of research and refinement of these techniques, this all looks possible to make happen within a year (Hegota fork). firefly.social/post/bsky/qmaj…

@zeebradoom Yeah checked, thx thx

@StackDigest nice breakdown, you made it on the MEV letter

🧵 Glamsterdam Gas Repricing Breakdown Ethereum’s upcoming Glamsterdam upgrade isn’t just about scaling. It introduces ePBS, BAL, and a full gas repricing overhaul under one core principle: “Safe Scalability.”