In any MPC protocol, outputs are always first learned upon receipt of some message Whoever receives that message will have the option to abandon the protocol without sharing the output This is described in Pragmatic MPC p25: In any message-based two-party protocol, one party will learn the final output before the other. If that party is corrupt and malicious, they may simply refuse to send the last message to the honest party and thereby prevent the honest party from learning the output. Pragmatic MPC p25 also seems to suggest this is an unavoidable problem: Usually the possibility of blocking outputs to honest parties is not written explicitly in the description of the functionality. Instead, it is generally understood that when discussing security against malicious adversaries, the adversary has control over output delivery to honest parties and output fairness is not expected.

The CRT states that if you have $M = \prod_{i=0}^{n-1} m_i$ and $m_i$ are all co-prime, then every number mod $M$ is uniquely represented by its remainders mod $m_i$. Example Suppose $M=420$ and ${m_i}={5, 7, 12}$. \begin{align*} 37 &= 2 \mod 5 \ 37 &= 2 \mod 7 \ 37 &= 1 \mod 12 \end{align*}

WAX 4337 Compression Note: This doc is pre-Dencun. Blobs have changed the economics dramatically, but compression will still matter for future scalability. Here's another doc all about that. Based on the implemented and upcoming methods in the WAX project by PSE, supported by the Ethereum Foundation. We're here to support the ecosystem - everything is freely available and modular. You can use exactly these methods, and you can also remix the parts you like together with your own ideas. Source code is in our repository and we're available to help via discord. (WAX is also about the wonderful features enabled by 4337, but this doc focuses on fee optimization.)

WAX - The Impact of Blobs on Compression tl;dr - The economic pressure for compression has temporarily disappeared. This situation might persist for years. This is a good thing, and provides space for more standardization and improvement before efforts need to focus on implementation. Compression still has a huge role to play in a future that brings enough demand to require it. Blobs have changed compression economics far more than I expected. I did always say that we simply won't know how much blob data will cost until it arrives. That was true, but I also figured that the 100x reduction I'd heard was probably a bit optimistic, and hoped only for 10-20x. What reduction factor are we seeing instead? 400,000,000,000x

General-purpose Ethereum L2s need to charge fees for two things: As an Ethereum-compatible chain, they charge for their own gas just like Ethereum does. The amount of L1 gas they'll need to commit themselves to your transaction on L1. This is mostly about making the calldata of your transaction available on L1. To do this, every L2 transaction effectively consumes an amount of L1 gas and an amount of L2 gas. To clarify, here's what those terms mean: L1 gas: The amount of gas the L2 will need to spend on L1 to support your transaction, charged at the L1 gas price L2 gas: The amount of gas used directly by the L2 chain itself (in accordance with the ethereum yellowpaper), charged at the L2 gas price

tl;dr BLSWallet is currently more expensive for ordinary users, because our current expander doesn't work for them. (The expander is essential, not just nice-to-have.) Let's fix this by creating a better expander. This new expander will also delegate to specialized expanders at the top-level, so that future dApps can add specialized expanders. This avoids the need for dApps to run dedicated aggregators - instead they stay in the same ecosystem and everyone benefits from larger bundles and therefore lower costs. TODO: This proposal focuses on minimizing L1 (calldata) costs. This can be done to great effect, but the cost of L2 gas is much higher than expected (even before the expander's L2 gas), and may be prohibitive. The Problem The use of BLS in BLSWallet and the whole point of bundling is about delivering cheaper transactions by only needing 1 signature instead of N signatures. We use accounts' BLS public keys to identify them, and they are 128 bytes long. Ordinary ETH transfers are only 117 bytes long, so we're already 11 bytes over-budget, even if the signature cost was zero, and before including nonce, value, and, destination address.

Key Findings PBS/MEV-boost/flashbots are L1 only, so not relevant (need to look into other MEV stuff though) USDC transactions on Arbitrum with BLSWallet might cost under 1c (USD) A subsidy could be effective in enabling early adopters to pay the longer-term expected cost instead of needing to cover the relatively unshared fixed bundle costs, which might cost up to USD$13,000/month Sending gasless transactions that pay tx.origin to RPC nodes on Arbitrum (both infura and arb1.arbitrum.io) are NOT getting run Offering free money by simply calling collect() is also not getting picked up EIP-1559 effectively prohibits gasless EOA transactions Legacy transactions are interpreted as 1559 (type 2) transactions by using gasPrice for both maxFeePerGas and maxPriorityFeePerGas

Previous Doc Outlined options for our 4337 strategy. The current doc expands on the first option - to fully embrace 4337. Vanilla Ethereum Transactions (To assist with upcoming comparisons) 4337 Ideal Flow (Note that we are only considering 4337's aggregate ops in this doc.) Under 4337, users own a contract wallet instead of an EOA account. 4337 defines a very special contract called EntryPoint which coordinates signature verification and gas payments, and passes on the actual on-chain actions to the contract wallets.

1. Fully embrace 4337 Drop support for directly calling VerificationGateway for ordinary transactions and pivot to only using the 4337 EntryPoint contract Use the 4337 fee/gas mechanism Stop developing the model where the wallet adds an explicit tx.origin payment Continue to explore/promote an ecosystem where dApps can pay tx.origin, allowing us to set the 4337 fee fields to zero when this is available (relying on mev/etc to identify these opportunities) This seems by far the best option. We can still promote an ecosystem where dApps pay tx.origin and enable us to set the 4337 fee fields to zero. This will always be a (perhaps rather small) subset of dApps, so we need to primarily support a payment mechanism that is universal, so dApps paying tx.origin is secondary. I also believe we should not pursue a model where the user simply includes an extra tx.origin payment. It diverges from the 4337 ecosystem without benefit. At the very least, these tx.origin payments should be tied to BASEFEE for stability, but... that's just 4337. Let's just do that.

Summary Create a 4337 EntryPoint contract which converts the 4337 UserOperation to a Bundle and calls processBundle on the VerificationGateway Include simulateValidation by doing the same thing, include require(msg.sender == address(0)), and just return (0,0) for (preOpGas,prefund) This way, when a wallet makes an eth_sendUserOperation call, the node can accept it into the 4337 UserOperation mempool Once in the UserOperation mempool, participants that are aware of our 4337 EntryPoint can convert these UserOperations into bundles, aggregate them (taking advantage of BLS signature aggregation), and submit the processBundle call if it is profitable for them to do so How Wallets Can Integrate BLSWallet This Way