What: a conference about p2p, focused on DHTs, discovery, and gossip. When: Thu, Aug 31, right after SBC; 10am-5pm. Where: Fischer Conference Center @ Arrillaga Alumni Center, Stanford. Why: to improve the performance and security of permissionless protocols Brought to you by: Ethereum Foundation and volunteers. The recordings for 2022 can be found here. Registration The conference is currently full. Thank you for all your applications!
8/30/2023JSON-RPC Specification There are several opportunities to contribute to the JSON-RPC specification. A few examples are: Automated testing Mostly writing go to integrate into Hive. See the example JSON-RPC tests here. The idea is to intercept both the requests and responses and validate them against the spec schema. Improve documentation tooling There is a frontend for the documentation written in typescript that could use improvements. The code for that UI is here. It's using the React framework which is super popular and would be a great thing to learn if you want to do more frontend engineering. Improve documentation
2/1/2022Introduction EIP-3074 adds a powerful new primitive to Ethereum that allows EOAs to act as smart contract wallets. This will allow many new use cases, including transaction batching and account recovery. If you are unfamiliar with this EIP, please review this thread. Statement of Work (Part 1) The first portion of work is focused on learning how EIP-3074 can be used. The learnings+research from this stage will feed directly into the next stage where the production contracts and integrations are completed. Total grant ask = $18,000 proof-of-concept Uniswap integration = $12,000
6/7/2021Signing a malicious tx In this threat model, we'll assume that an adversary can trick a user into signing an invalid transaction. EOA: if a user secures their assets in an EOA and they sign an arbitrary malicious transaction, the worst that can be done is their most valuable asset will be compromised. Generally, there isn't the ability to "batch" actions together so the attacker will should go after the user's most valuable asset. In the future, it's likely that more contracts will support meta-txs and standards for batched actions will emerge or that the protocol will support batching for EOAs. This would make it possible for an attacker to appropriate more than one of a users assets. Smart Contract Wallet: if a user secures their assets with a smart contract wallet, they are vulnerable in a similar way as above. The exact vulnerability is dependent on the implementation of the wallet contract they are using. If the wallet contract mimics the same functionality as the protocol, the user can lose their single most valuable asset. If the wallet supports batching, they can have their account completely emptied. One advantage is that contracts can impose limits for transfers and fallback to multi-sig authentication for large transfers. This would require parsing the calldata to understand how much is being transferred (ether is trivial to check, other assets -- not as much). EIP-3074: in this case we'll assume the invoker contract is bug-free (this is the same assumption made above for smart contract wallets, we'll explore contract bugs later). By bug-free, we mean the user's transaction is not malleable. What the user signs is what will happen. In this case, the worst that can be done is equivalent to that of a smart contract wallet. In the simple case, the user will lose their single most valuable asset. The caveat here is that EIP-3074 does not permit value transfers from the authorized account. Therefore, the attacker would not have access to the user's ether stored in their account balance. If the invoker supports batching, one signature for $N$ actions, the user will lose every valuable asset in their account. Like smart contract wallets, it's possible for the invoker to impose transfer limits on an account -- minimizing the potential damage. EIP-3074 can potentially be made worse though. If a user secures their key with a hardware wallet and the hardware wallet supports arbitrary invoker addresses, an adversary could trick a user into signing an EIP-3074 message to a malicious invoker. This should be combated by the hardware wallet not allowing arbitrary invokers to be signed over. Only a trusted list of invokers should be preloaded onto hardware wallets. This could be updated overtime by updating the hardware wallet's firmware (if we can't do this securely, we have other problems). If hardware wallets impose this restriction, the vulnerabilities here are equivalent to using a smart contract wallet. Compromised computer In this threat model, we'll assume an adversary has complete control of a user's computer.
3/17/2021