Blockchain is an experiment spanning multiple disciplines and a radiant spark of our era. In this field filled with a cacophony of voices, some focus on technological advancements, while others chase wealth. There’s nothing inherently wrong with this. Yet, I often find myself lost, especially when my attention is drawn to the rise and fall of token prices, as if everything is merely a game of numbers. In such moments, I remind myself that blockchain’s significance goes far beyond the noise. It represents an unprecedented revolution across dimensions of time and space. To witness its birth and growth is already a privilege; to participate in it is even rarer! Because of this, there is no need to stop for temporary setbacks. Every hard fork, every evolution of blockchain is not by chance, nor is it the product of someone’s meticulous design, but rather the choice of the times. It carries its own dreams, traversing space and time, pointing toward a future that is exciting yet impossible to predict. I also understand there’s no need to demand a perfect path—just follow it. For even the smallest contribution made during this journey will become part of its future. 区块链是一场跨越多个学科的实验，也是时代的一抹耀光。在这个领域众声喧哗，有人关注技术的进步、有人追逐财富。当然，这无可厚非。但我时常感到迷茫，尤其是当目光被币价的起落所吸引，仿佛一切都只是数字间的博弈。

When researching the integration of privacy protocols within wallets, I found that stealth addresses and privacy protocols (e.g., Labyrinth) are a perfect match. Stealth addresses allow generating one-time addresses without exposing any on-chain address associations, while privacy protocols enable confidential transactions between public addresses or between public addresses and stealth addresses. However, integrating these privacy features into contract wallet is more complex compared to EOA wallet. The main challenge lies in the fact that contract wallet do not have fixed private key like EOA wallet. A contract wallet’s signer can be based on any algorithm and can be replaced at any time. 1. Stealth Address For EOA wallet, the primary challenge in implementing stealth addresses is creating a user-friendly UI to make them easier to use. For contract wallet, the challenge is far greater because contract wallet lack a (fixed) signer. Without a fixed signer, the classic stealth address algorithm cannot be used. This could lead to issues such as losing access to assets after social recovery or being unable to use the classic stealth address algorithm if the contract wallet’s key is not based on Elliptic Curve cryptography. While contract wallet could choose to expose an ECDSA public key through a interface specifically for stealth addresses, this approach has a significant drawback: user need to manage an additional private key (or seed phrase), which significantly degrades the user experience.

EIP-3074: AUTH and AUTHCALL opcodes represents a significant advancement. It allows users to use some features of smart wallets without paying contract deploy gas fees: Gas sponsor (e.g., paying gas fees using ERC20 tokens without native token). Batch transactions (such as executing token approval and swap in one transaction). Conditional execution (e.g., only allowing transaction to execute when blockNumber < x). Compared to ERC-4337, EOA wallets can benefit immediately by supporting EIP-3074. However, since EIP-3074 is based on EOA, it currently does not support exciting features already in ERC-4337, such as 'change owner,' 'use any signature algorithm,' and 'social recovery.'

[EN] [zh-CN] ENS 在 Layer1 中的交互成本阻碍了其广泛采用。 由于 SoulWallet 是基于合约的钱包（意味着我们无法实现一致的多链地址），确保用户拥有低成本的 ENS 对于良好的体验至关重要。 目前，我们拥有 swl.eth 域名，旨在为用户提供几乎免费的二级域名（例如 bob.swl.eth）。基本上有两种解决方案： 完全将所有二级域名存储在区块链之外，使用 EIP-3668。优点 👍：用户在使用二级域名期间零 gas 费用。 缺点 👎：完全集中化（从长远来看，这是不可持续的）。

[EN] [zh-CN] The interaction costs of ENS on Layer1 hinder its widespread adoption. As SoulWallet is a contract-based wallet (meaning we can't achieve consistent multi-chain addresses), ensuring a low-cost ENS for users is crucial for a good experience. Currently, we own the swl.eth domain and aim to offer users nearly free subdomains (e.g., bob.swl.eth). There are basically two solutions: Completely store all subdomains outside the blockchain using EIP-3668.Pros 👍: Zero gas fees for users during the subdomain usage. Cons 👎: Completely centralized (which is unsustainable in the long run).

I've spent some time with web self-custody wallets recently and initially wrote an article about passkeys: A Path to “Easy and Secure” Account, which argues that using passkey-based wallets through ZKP (Zero-Knowledge Proofs) is a safer option for most users. Thanks to webauthn, it's even possible to use self-custody wallets in the browser more simply and securely: SimplicityNo need to download any apps or browser extensions, just access the wallet website using mainstream browsers (Chrome, Safari, Edge, etc.). Security The private key is hosted within the system, especially on devices with hardware security chip support from Apple, Google, Microsoft.

ubuntu@AWS shell install OutlineVPN intalll CloudFlare Warp-Cli https://pkg.cloudflareclient.com/ apt install cloudflare-warp warp-cli register warp-cli set-mode proxy warp-cli connect test 127.0.0.1:40000

refer: https://hackmd.io/@axiom/HkAM8sp-T E1: Maximum // _ _ _ ___ _____ ______ _____ _ // | | | | | | |__ \| __ \| ____| __ \| | // | |__| | __ _| | ___ ) | |__) | |__ | |__) | | // | __ |/ _` | |/ _ \ / /| _ /| __| | ___/| | // | | | | (_| | | (_) / /_| | \ \| |____| | | |____ // |_| |_|\__,_|_|\___/____|_| \_\______|_| |______| //

(This article assumes you have some knowledge of Ethereum smart contracts, passkey, and related technologies.) For a self-custodial Ethereum smart contract wallet, security primarily relies on the security of the "contract and frontend." However, we must not overlook the choice of signature algorithms and their impact on security: The most widely adopted algorithm currently is SECP256K1. While SECP256K1 is mathematically secure, mathematical security does not necessarily equate to security in real-world usage. Risks include not only the risk of private key loss but also the risk of private key theft by malware or brute force attacks due to weak wallet passwords. What about WebAuthN? With WebAuthN, wallets can directly invoke the SECP256R1 algorithm protected by a secure chip on the device for signing (link1, link2). This approach offers higher security compared to users storing their private keys in a file on their computer. However, the use of SECP256R1 is not without issues, and we need to consider the following:

[EN] We all know that in digital wallets, signing keys represent ownership of the wallet, and every "self-custody wallet" developer strives to make the wallet capable of securely storing the keys. However, many may not be aware that the security level of the same wallet on different devices can vary. Native Wallet ApplicationsiOS: Developers can use passkey and keychain to generate or store keys (using passkey means Ethereum accounts must support secp256r1 signature verification, which currently requires more than 300,000 gas). Android: Developers can use keystore to store keys. Windows: Passkey via Windows Hello and Credential Manager can be used for key management. Mac: Developers can use passkey and keychain to store keys. This is especially important for devices that support Hardware Security Modules (HSM).

I found a significant overlooked vulnerability in contract wallets: use mapping(address => address) LinkedArray to store owners. Let's examine the owner storage in some wallet contracts: Safe wallet link 1: // link 1 mapping(address => address) internal owners; function isOwner(address owner) public view returns (bool) { return owner != SENTINEL_OWNERS && owners[owner] != address(0);

We are working on the first version of soulwallet after the hackathon version. We would appreciate your feedback on contract design. Contract draft source-code: SoulWallet.sol We are grateful to ERC-6900 for providing us with some inspiration, and we have also borrowed some implementations from Safe. In general, the current draft of soulwallet supports modules and plugins. A module is an external contract, while a plugin is a contract that implements the interfaces described in IPlugin.sol. interface IPlugin is IPluggable { /**

Context: The wallet use delegatecall to implement flexible plugins. It is not allowed for hacker(stole your private key) to add malicious plugins to destroyed the storage slot before social recovery (social recovery will never be able to run if some storage slot destroyed). Implementation suggestions: The wallet owner must have a 48-hour delay confirmation period for adding any new plugins (or can be immediately effective through joint signature by owner and guardian). (This prevents the wallet from being stolen by hackers and destroying the storage, causing social recovery to not run as expected.) The wallet contract needs to add a simulate(calldata) function, where calldata is all the operations that the user will execute (if key storage such as owner, guardian, etc. are modified after executing the user's operation, the specific information that is modified should be reverted). The wallet UI side should call this function in advance before the user executes any operation, if key storage is not modified as expected, the user should be prompted to avoid the wallet storage being destroyed by contract wallet plugin's bug. more contexts :

Bundler is an indispensable part of the EIP4337 ecosystem, and users interact with the bundler’s RPC endpoint. And bundler needs to implement a very strict UserOperation simulation policy to prevent risk. Implementing bundlers in Layer1 is a challenge (not discuss now), but the implementation of bundler in Layer2 will be more challenging: Sequencer centralizationSequencer centralization would make it impossible (or difficult) to create a public userOp mempool, which would make each bundler and the whole system more vulnerable to attacks (bundler as relays, and unless Layer2 supports adding new transaction type (e.g., Layer2 supports guaranteeing that the pre-defined storage slots in a transaction are not modified otherwise the transaction is rejected), the bundler's operator will face a significant security risk). Note: Some Layer2 is exploring decentralized Sequencer, but I haven't found more information at the moment. If you have relevant information, I believe everyone will appreciate your sharing. A great update（thank to heymarcopolox）！！！ https://notes.ethereum.org/@yoav/SkaX2lS9j eth client in development:https://github.com/tynes/go-ethereum/blob/ad0cede82fdf62b796f3c6d584c0ace408cdd32c/internal/ethapi/api.go#L1785 Gas fee calculation complexity