Privacy in Ethereum – Secret Address (Stealth Address)

Source: Denglian Community

introduce

A major pain point facing Web3 encryption users is the lack of privacy.All transactions are visible on public ledgers and are increasingly associated with a clearly visible ENS name, which makes users less motivated when performing certain activities or leads them to perform in a way that increases user experience friction.These activities.An example is simply transferring funds from hot wallets to cold wallets or vice versa.Users may not want one wallet to be connected to another because they may not want their cold wallet balance to be seen.Currently, Ethereum addresses do not work like private bank accounts, as everyone can see your wallet, and more and more, your social activities (SBT, proof, activities on various dapps, etc.) are alsoWill be seen.Because of this, Vitalik calls privacy what Ethereum needs to go throughOne of the three major technological transformations, so as to be useful to ordinary users.

Using existing privacy solutions like Tornado Cash, the experience is not ideal for several reasons.First of all: Users will reasonably worry that their address will be blacklisted on centralized exchanges or other platforms.Secondly, the interactive user experience with services such as Tornado Cash is not friendly and is actually only suitable for highly skilled users.

Secret addresses provide users with a privacy similar to what they take for granted in a private bank account and are implemented in an easy-to-understand way.Furthermore, innovation around hidden addresses means we can do this in a way that complies with anti-money laundering regulations in multiple jurisdictions.

Users’ privacy needs

Although research on privacy attitudes toward privacy by web and Web3 users is not extensive, the following studies were found through web searches, and the results are roughly consistent, indicating a clear need for transaction privacy.

1. A survey conducted in 2022, published by Simin Ghesmati et al. entitledUser-perceived privacy in blockchainIn the paper, it is stated thatHalf of the respondents said transaction privacy is very important to them”. While this study has a greater relationship with Bitcoin, Ethereum users may have similar attitudes. However, the sample size of this study was relatively small (14 participants).

2. Another interesting study came from 2022, published inFrontiersThe title isPolitical, economic, and government attitudes of blockchain users, This study is more comprehensive, and a total of 3,710 crypto users were investigated.The results show that about a quarter of respondents said their privacy was “The most important feature in blockchain and cryptocurrencies”.

1. In terms of overall attitude toward privacy,ConsensysA PublishedWeb3 and crypto global survey 2023, in which an online survey of 15,158 people from 15 countries covered various topics related to the web, not just encryption.The survey found that 83% of respondents believed data privacy was important, while only 45% said they trust the current use of their data and personal information by Internet services.

2. A UK Financial Services Compensation Schemeinvestigation, released in April 2023, highlighting that 9% of respondents will “A desire for anonymity/privacy” As the reason they invest in cryptocurrencies.

Adoption of secret transaction agreements

RailgunThe usage data is impressive, and the use of the protocol appears to have steadily grown over time, reaching over $70 million in total locked value (TVL) and $2 billion in trading volume as of November 2024.

TVL (USD) Railgun on Ethereum Main Network — Source: Railgun — DefiLlama

UmbraThe number of users has also steadily increased (the number of people who registered secret addresses to their ENS), approaching nearly 77,000 as of November 2024:

Umbra cumulative number of registered people (cross-chain) — Source: dune.com

If we look at the most well-known (and now unfortunately notorious) privacy protocol in Ethereum, Tornado Cash, we can see that despite the contract address being technically included in OFAC’s SDN list, it is still being used in large quantities.

The following figure shows the TVL of Tornado Cash over time.We can observe that from the peak around October 2021, the first major decline in TVL coincided with the overall sell-off in the crypto market, and the second major decline occurred in August 2022, which coincided with OFAC’s Tornado Cash listOn the SDN list, the third significant decline corresponds to the re-designation of OFAC in November 2022.However, despite sanctions, Tornado Cash usage has been growing steadily since then, with TVL approaching $600 million.This is a strong testament to the need for basic transaction privacy in Ethereum.

TVL (USD) Tornado Cash on Ethereum Main Network — Source: Tornado Cash — DefiLlama

The current situation of hidden addresses

This study identified 4 main solutions currently produced on the EVM chain, which are:

• Fluidkey

• Umbra

• Labyrinth

• Railgun

Fluidkey and Umbra are based on the Ethereum standards, which are:

• ERC-5564: Secret Address Agreement

• ERC-6538: Hidden Metal Address Registration

Labyrinth and Railgun are based onzerocash protocol(zcashAlso based on this), the protocol uses a protection pool where users deposit funds.Zerocash uses the concept of “notes”, which is basically an encrypted representation of value, capable of achieving private transactions.Each note includes a hidden value, owner key and a unique number (an invalidator), which uses zk-SNARKs to verify ownership without revealing details, thereby transferring the value in the note.When a bill is spent, its invalidator is revealed to prevent double spending, while creating new bills for the receiver, forming a UTXO system within the protection pool.

At a high level, the basic principle of a hidden address is that a third party can send funds to an address that has never existed, and the intended recipient can find and control the address (i.e., the funds can be subsequently spent).

The erc-5564 standard specifies a mechanism in which the receiver can publish a hidden meta address from which a new Ethereum address can be derived.Anyone who wishes to send funds to the recipient can generate a new address from the hidden element address and allow the recipient to learn about the funds without any direct communication.All hidden addresses are implemented based on this basic premise.

How does secret address work

The secret element address is essentially a connection between two compressed public keys, called the “spension key” and the “view key” respectively.The secret meta address uses the EIP-3770 chain-specific address format and adds the “st:” prefix.Here is an example of a hidden address:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

To simplify, this secret address can be associated with a normal Ethereum address (and thus ENS), making it easier to send funds to the secret address owner.To send funds, the sender parses the above address and uses the EIP-5564 standard to create a temporary public key from which the secret address is derived.The sender sends the funds to a new hidden address, usually through a singleton contract where the receiver of all hidden addresses listens to events.The contract issues an “Announcement” event, which the recipient can subscribe to.Whenever an announcement event is issued, the recipient checks the temporary public key in the announcement, combines it with their view private key to determine whether they have the ability to spend the funds sent to the hidden address.If so, the wallet/client they use will remember the hidden address and the corresponding funds and add them to the user’s displayed balance.To actually spend these funds, they can sign the transaction using a private spending key.

The following chart outlines the entire process more clearly:

Remember that this process is completely non-interactive, which means there is no direct communication between the sender and the receiver, which means there is actually no link between the sender and the receiver that a third party can observe.

However, in order for this to work properly, the receiver must inform the sender of their secret address.One way to do this is to useeip-6538 Hidden element address registration form.This is a singleton contract that allows users to register a secret meta address to a normal Ethereum address, which the sender can look for.This allows the sender to parse the normal address from the ENS and then look up the relevant hidden meta addresses from the registry.

The scheme breaks the link between the sender and the receiver, allowing them both to avoid the entire world knowing their affairs.However, there are some things to note:

• When the recipient goes to spend the funds, the object they transfer the funds will see that the funds are from the original sender (i.e., they can see the address where the funds are transferred and who sent the funds to that address before).This means that the transfer chains remain intact and traceable, but they are only unrelated to the recipients involved (unless the recipient does something like sending funds to a non-hidden address they are known to).Note that this only works with erc-5564 implementations and not with Railgun or Labyrinth.

• Another side effect of the above problem is that to maintain optimal privacy, users may need to keep their funds in the secret address they were originally sent to until they really need them, rather than merging them under one address.This represents the additional overhead of remembering addresses and subsequently spending funds on those addresses, as the amount you wish to transfer needs to be taken from the portfolio of funds for multiple other addresses.

• In order to transfer funds from that address, the recipient needs to provide some ETH to the address to pay gas, which may de-anonymize the recipient.This is a known issue with hidden addresses and one of the reasons many implementations support eip-4337 and payers.

• One disadvantage of the hidden address scheme is that the receiver needs to monitor the blockchain to obtainannouncementand check each announcement to determine if they received the funds.This is obviously an unrealistic overhead for most users, especially when receiving funds from multiple networks.To make this process more efficient, the standard specifies a “view tag”, a truncated hash derived from a shared secret that can be used to quickly discard transactions that are obviously not intended to be sent to them.By using the View Tag, the performance on the desktop is not that bad, but it may be more noticeable on mobile devices.The only moment when the performance drop is really obvious is if the wallet is recovering, in which case the wallet needs to scan every address since the on-chain contract deployment, which is very time-consuming.

• To resolve this issue, users can choose to share a private viewing key with a trusted third party.This third-party service can monitor a variety of networks and notify users when they receive funds.Of course, this brings a trade-off: While third parties can’t actually spend users’ funds (they don’t have a private spending key), they can see all the funds sent to a specific recipient, which means that users need to trust theirprivacy.Fluidkey does this by default.

• The standard secret address protocol, namely ERC-5564, is designed to facilitate the transfer of privacy protection, however, non-financial use cases (such as calling arbitrary smart contract functions) require more engineering, often implementation-specific.

Comparison matrix

We can compare the four hidden address implementations discussed in this article in a variety of ways.All implementations have subtle differences and tradeoffs, but perhaps the most important point is the fuzzing of traceability and value.

While both Fluidkey and Umbra allow funds to be transferred to standard Ethereum addresses while breaking any link to the recipient’s identity, they still retain the traceability of transactions, meaning the sender will be against anyone who checks the transaction history of the secret addressIt is visible.This means that if you receive funds at a hidden address, the person you decide to send these funds to will see where they are from.In addition, the actual value of transfer is also visible.Railgun and Labyrinth hide the sender and the value of the sender, but at the cost of this it all happens within a single contract rather than as a normal transaction to a normal Ethereum address.

The figure below shows the mutual comparison of the protocols we discussed in this article on these two important comparative dimensions.

To explore these differences in more detail, here are the comparison matrix of the four major hidden address protocols on six main dimensions:

1. Complete end-to-end privacy (only sender and receiver see payment information)

2. Confidentiality forward.Funds received through concealment transactions do not allow a second recipient to see the source of the funds

3. Follow erc-5564 and erc-6538 standards

4. Implements a scalable modular architecture that allows integration with third-party dapps

5. Does the implementation provide an SDK that developers can use to integrate?

6. Does the solution provide compliance with some kind of deanonymization support?

7. Does the design support obfuscation of the amount/value transferred?

The following section captures some other nuances and differences in more detail.Each implementation has interesting nuances, which may or may not affect your use case.

For example: In Fluidkey: All transactions are directly transferred to the hidden address on the chain, while Umbra**:** Only ETH is transferred to the hidden address on the chain, and tokens are transferred to the central contract. Like Railgun and Labyrinth, all transactions areAll are transferred to the core contract, rather than directly to the hidden address on the chain.

In-depth discussion on the implementation of hidden addresses

Fluidkey

Fluidkeyis an implementation of erc-5564 that allows users to send, receive, exchange and bridge ETH and erc-20 tokens.At the time of writing, Fluidkey has been deployed on Base, Optimism, Arbitrum, Polygon, Gnosis, and Ethereum mainnets.

Users interact with Fluidkey through their web user interface.When they first log in with their wallet, they sign a key generation message from which they deduce their viewing and spending keys.These same keys are regenerated in the same way each time the user enters the app.

Fluidkey has several different ways than other implementations.One of the differences is that users share their private viewing key with Fluidkey (actually oneBIP-32derive node).This enables Fluidkey to generate hidden addresses for users and notify users when they receive payment for those addresses.However, this also means that Fluidkey has the ability to view users’ earning transactions and balances, which is a trade-off.However, Fluidkey remains completely self-custody.

Another interesting aspect of Fluidkey’s design is that it deploys a smart contract account for each new hidden address.This only happens when funds funded by self-concealed addresses are used.Smart Account is a 1/1 secure account that allows operations such as gas sponsorship, making it easier to manage various hidden addresses.For more information on this, please check out theirTechnical explanation.

While Fluidkey does retain visibility to user accounts, this may potentially be an advantage in compliance, although the exact framework for how Fluidkey will handle potential future law enforcement requests has not been made public.They are located in Switzerland and despite the local laws, data protection laws are very clear and powerful – there must be very clear reasons to share data, and the matter will be reviewed by the court (See this articleLearn about a good overview of Swiss privacy laws).

Users can also fully export their transactions, or share their viewing keys with third parties, such as accountants, which is especially useful for businesses.It is worth noting that, according to the erc-5564 specification, the sharing of public keys is “all or nothing”, which means it cannot disclose orphaned single transactions alone.Furthermore, like all erc-5564 implementations, traceability is not broken—just the correlation with the user—which means that the transaction history of each hidden address is publicly available to those who have the viewing key.A less well-known feature of Fluidkey is the ability to rotate view keys, which will allow users to use a new view key per month and share view access for a specific month with third parties only.

One advantage of the Fluidkey method is that the hidden address itself is not generated by the sender, but is pseudo-randomly generated by Fluidkey every time he querys ENS.This is faster because users do not have to scan through announcement event to identify transactions that they are recipients.This also means that the sender does not need a hidden address wallet to generate a hidden address for the recipient—they just need to send funds like other addresses.This also means no registration contract is involved, which is unique and a major advantage of Fluidkey’s design.

It is worth mentioning that Fluidkey is committed to completely self-keeping, and they have open sourced their library of hidden account kits and, unlikely, Fluidkey disappears overnight, there are several independent development recovery.The interface is available, which means funds will never be locked or stuck.

Address abstraction

By using smart contract accounts, Fluidkey can automatically abstractly manage individual hidden addresses.This means that if you want to transfer a specific amount from your balance in each hidden address to a specific recipient, Fluidkey can automatically calculate the address combination used to transfer funds, handling all gas fees and contract deployments, all of whichProceed in the background.Fluidkey also allows users to pass aLabelThe cool feature of the address to be combined allows users to mark the address as different categories.

ENS Analysis

Fluidkey requires users to create an ENS name exclusive to Fluidkey.These static names come in two forms: username.fkey.id and username.fkey.eth, one is the URL to the web interface that sends funds to someone, and the other is the standard ENS name that can be used with the wallet.

ENS settings useENS offchain resolver(also known aserc-3668: CCIP Read) to return the hidden address.Each time the offline resolver is queryed, it generates and returns a new hidden address for the corresponding ENS name.This is a great feature because it allows the user to have a single human-readable ENS name while still retaining the privacy of the hidden address, because the generated hidden address cannot be traced back to the ENS name.

cost

Fluidkey is free to use and there is no charge.When you want to spend money, each address with funds needs to deploy a Safe contract fee.However, despite being relatively expensive on the mainnet, this is actually trivial on L2, usually less than 1 cent, even if multiple hidden addresses are combined into a single transfer.

They can also do gas sponsorship through Safe deployments—they calculate the gas fee and deduct it from the user’s balance, even if it is a token—in which case the forwarder deploys Safe and transfers tokens on behalf of the user.

Umbra Cash

UmbrayesScopeliftImplemented eip-5564 + eip6538.When users log in to the Umbra app, they go through a setup phase where they sign a message from which they derive expenses and view keys and corresponding hiding meta addresses.They then register this hidden meta address to the on-chain registry of their main wallet address.This is the difference between implementation and Fluidkey.

Umbra’s implementation of erc-5564 is closest to the specification because they cannot access the user’s key.While this means Umbra (or anyone else) can’t see the user’s funds, it does mean that in order to receive funds, the sender must have an erc-5564-compatible wallet (or Umbra app) to generate their occultsaddress.

When someone wantssendWhen funds are given to users, they usually use the Umbra app to complete it.Basically, the Umbra app looks for the hidden meta-address registered to the ENS name/wallet address and generates a hidden address.Recipients can log in to the Umbra app and scan for any funds sent to their hidden address since the last login.Thanks to some clever cache, this seems to take only 10-15 seconds for weekly scans, although users can also choose to specify a block range to narrow down the scan.Umbra v2 will include the use of view tags, which will speed up the process further.

Reposter

One of the problems with the hidden address we mentioned earlier is that in order for the recipient to spend the funds sent to the hidden address, the address needs to have ETH or other necessary gas tokens to pay for the transaction fee.On most networks, this is usually not a problem if the hidden address initially receives ETH.However, if an erc-20 token or NFT is received by a hidden address, the act of providing gas to the address with ETH may associate that address with other addresses of the user, thus losing privacy.

To bypass this issue, Umbra used an involvedReposterstructure.When any non-ETH asset is sent to a Umbra user, it is actually sent to a special contract, rather than directly to a hidden address.Users can spend funds sent to their hidden address by sending metatransactions (from the Umbra app) to Umbra’s forwarders, who will transfer funds from the smart contract on behalf of the user.The forwarder will deduct some tokens to cover the cost of gas fees and initially only supports a certain number of tokens.

cost

Umbra contracts also charge small fees when transferring funds on networks with low transaction fees to curb spam.The reason is that spam increases the cost of scanning transactions to identify related transactions, so this is considered an acceptable trade-off.

Supported networks

Umbra is currently deployed on the Ethereum mainnet, as well as Optimism, Polygon, Gnosis Chain and Arbitrum.

Umbra sign up contracts have interesting designs.The deployment method uses create2 and standard create2 deployers, and the smart contract address is the same on any network.This means that if the contract exists on a given network, the client can make sure that this is the correct contract.Clients can be configured to add networks, and anyone can deploy to any network.They have normalized the bytecode, and the contract has no owner, which allows anyone to deploy registration and announcement contracts without permission on any chain.

Umbra v2

Scopelift is currently in developmentUmbra’s 2nd Edition, This release introduces a new modular architecture that allows core contract extensions to support new token standards or non-payment use cases.With this new architecture, third-party developers can build modules for any type of token standards, such as erc-1155, erc-7621, erc-4337-enabled payers, or anything else you can think of.Currently, Umbra core contract supports two scenarios, one for ETH and the other for erc-20.V2 will support many different scenarios.

Labyrinth

Labyrinthis a protocol that is not based on eip-5564 + eip6538, but uses zero-knowledge proof to add anonymity and privacy to transactions.Labyrinth’s white paper describes it as the “zkFi” middleware: “zkFi provides a packaging solution that acts as a privacy middleware with built-in compliance”. Built-in compliance refers to Labyrinth’s “selective deanonymization”, a complex solution that allows certain transactions to be deanonymous to specific authorized parties (i.e. legal institutions such as Interpol, etc.) while maintainingTransparent and open.

The core smart contracts used by Labyrinth include a multi-transaction and multi-asset pool that allows users to trade multiple assets in a single transaction.To spend assets, users scan the network and get encrypted notes data, decrypt the notes, and filter out the assets they want to spend.The user then creates a ZKP that includes the signature keys for the transaction and the notes associated with the transactions they want to spend.

Part of the Labyrinth core contract includes a conversion contract that interfaces with modular proxy contracts that are essentially proxying to external contracts.So, for example: If the user wants to interact with Uniswap using Labyrinth, the user will build a transaction that will invoke the exchange operation on the Uniswap pool using the conversion contract through the proxy contract of Uniswap.

Labyrinth’s zkFi protocol uses “notes” to track balances and transfers.A bill is essentially a data structure that describes a certain number of assets and their address to which they belong.The client stores the information needed to rebuild the notes and uses this information to spend assets.The commitment to the notes (hash of asset ID, owner, and value) is stored in the Merkel tree on the chain.In fact, Labyrinth uses two Merkel trees, one for the ticket and one for the root address.

The note data structure contains the following:

• assetId: The identifier of the asset represented by this note (ETH, WBTC, MATIC, etc.).

• value: The value or amount represented by the notes.

• leafIndex: This note will be inserted into the leaf node index of the promise Merkel tree.

• blinding: A random protection factor.

• rootAddress: The root address of the user with expenditure permission.

• revoker: The public key point of the selected undoor.

You will notice that the above data structure does not contain assetsownerAny reference to this is strange because the promises recorded in the notes Merkel tree are asset ID, value andownerhash of .In fact, the owner is calculated from the root address, the revoker, and the random protection factor, so for external observers, the owner is actually a new address generated by each new transaction.

Protection pool

Regarding Labyrinth, it is particularly interesting that it is slightly different from the traditional protocol based on hidden addresses, and the Asset Pool is actually a protection pool that uses the notes to create a shielded UTXO pool, thus providing a former for transactions.Towards confidentiality.Recall that in the eip-5564 implementation, the user transfer object will be able to view the source of these funds.In other words, Alice pays Bob with a secret address, and Bob pays him to Charlie, so Charlie can now see Bob receives the funds from Alice initially, and so on.This is not the case with Labyrinth’s protection pool.

To understand how this protection pool works, we need to see how funds are transferred within the protocol:

The user’s balance in the protection pool is the sum of the notes of the corresponding assets.To spend these notes, users need to reveal the “invalid logo” of those notes.An invalid logo is uniquely related to a note, and once the note is spent, the invalid logo is marked to prevent double consumption and create a new note based on the spent note.Multiple notes for the same asset can be merged, and multiple new notes can be created.An invalid identifier is a hash of (?,?,?), where ? is the index of the note commitment in the Merkel tree, ? is the promise, and ? is a random element, also known as the protection factor.

The recipients of secret transaction transfers identify the transfer in the same way as eip-5564, because they listen to events sent from the core contract and determine the secret address from which they will be able to send funds and record those addresses locally.The speed of identifying incoming funds has also been improved by leveraging view tags and asynchronously cache and synchronous notes throughout the application life cycle.

Research is currently underway to speed up the discovery process of receiving funds, and take a look at this proposal from Aztec:Request for Proposals: Note Discovery Protocol — Aztec.

In terms of spending money, users also have to generate a zk proof, which is different from the erc-6654 implementation that is basically a normal Ethereum address.Generating proof requires a compatible wallet with relatively good performance, and it takes about 20 seconds on mid-range Android devices.

Packers and converters

Labyrinth provides some good features that can solve some pain points in secret transactions.Transactions sent to the Labyrinth core contract are sent as user operations through the erc-4337 packager.This setting allows for the expense of notes without the need for ETH or transactional gas tokens, as users can use erc-4337 payers to pay gas for them, adding an additional layer of privacy.The only exception is the initial deposit, which is not submitted as a user action.Another benefit of using erc-4337 payers is the ability to pay gas through the transferred assets, even if they are erc-20 tokens, so Labyrinth exposes a gas price oracle API.

Another very good feature of Labyrinth is its modular architecture that allowsConverterContracts serve as agents for third-party decentralized applications.This not only allows users to transfer funds using hidden transactions, but also interact with third-party decentralized applications (such as DEXs such as Uniswap, Aave, Lido, etc.).These agentsConverter“The contract essentially implements a function that receives a certain amount of assets and outputs some assets. The basic logic exists in a third-party contract.

Compliance Solutions

Labyrinth ensures compliance and regulatory compliance through a framework called Selective Deanonymization (SeDe).

Recall that the data structure of the note contains a field called “Undoer”.The revoker is the address of a specific entity that can initiate the deanonymization process.The user must select at least one revoker from the predefined list.The revoker is not solely responsible for identifying potential illegal or inappropriate activities, but can respond to requests from law enforcement agencies.

The revoker does not have the ability to de-anonymize transactions directly, but they are responsible for initiating de-anonymization requests.These requests are published publicly to the Guardian, a substantive committee that monitors privacy and compliance.The guardian must vote to decide whether to allow deanonymization transactions.If the guardian can reach the quorum and vote for it, the revoker can decrypt the transaction data, thereby linking the relevant transaction with the previous transaction until the transaction chain is completely deanonymous.

This system creates a series of checks and balances because guardians cannot decide to reveal transaction data alone, and even if they collude, they cannot do anything without the revoker, and the revoker alone cannot do it with the majority of the guardian votes alone.Anything.

Railgun

RAILGUNIt is a secret transaction privacy system deployed on Ethereum, Binance Smart Chain, Polygon and Arbitrum.The protocol is similar in some ways to Labyrinth because it is based onnotes, these notes are stored as promises in the Merkel tree, forming a UTXO set, i.e. by creating new notes for other recipients to spend.This means that only the owner of the note can calculate its invalid identity, which is often generated based on the hash of the expenditure key and the index of the note in the Merkel tree.

The hidden meta addresses in Railgun use the prefix of “0zk”, similar to eip-5564, which is a combination of public viewing keys and public spending keys.However, Railgun uses the Ed25519 key on the BabyJubJub curve instead of ECDSA and secp256k1.Just like eip-5564, users scan all issued events in the Railgun contract and use their view key to determine which events represent transfers to their wallet.

Railgun uses aBroadcasterNetwork, these broadcasters are actually relays who receive the user’s metatransactions and broadcast the actual transactions to the corresponding blockchain to pay gas fees on behalf of the user.The transactions from users to broadcasters are encrypted and usedWaku AgreementConduct communication to protect end users’ anonymity.

Railgun adopts a modular architecture that allows it to interact with external smart contracts, providing functionality beyond simple transfers.It passesAdaptRelayThe contract achieves this, which protects and deprotects the tokens before and after interacting with an external contract, for example, unprotected token A, exchanges token B on an AMM, and protects token B back toOriginal owner.

In version 3, Railgun plans to leverage eip-4337 and supports traditional metatransactions.They hope to enable independent solvers to participate as broadcasters by maintaining a dedicated eip-4337 userop memory pool for Railgun.They are currently working with Umbra on this issue and identify edge cases and how to resolve them, see the Railgun v3 section below for more details.

cost

The Railgun Agreement charges a 0.25% fee for deposits and withdrawals.These fees will be sent to the DAO warehouse, which will be paid over time to the stakeholders of the RAIL governance tokens.In addition to the 0.25% deposit and withdrawal fees, broadcasters usually charge their own fees, which are usually about 10% of the gas fees for actual on-chain transactions.

Governance

Railgun has a governance system that allows for the submission of any form of proposal, and any changes to core contracts, including fiscal and governance contracts, must be made with a DAO proposal.Unusually, different instances of Railgun have their own governance.For example, Railgun has its own independent governance systems and tokens on Ethereum, Polygon and Binance Chain.

SDK and Cookbook

Railgun provides a comprehensive and well-documented SDK that wallet or DApp developers can use to build hidden address functionality through support for Railgun.Railgun also has a community-maintainedcookbook, provides a “recipe” that allows DApp developers to provide modules for Railgun, allowing users to interact with their DApps using Railgun.For example, a developer could write a recipe for DEX so that users with token balances in Railgun can exchange tokens privately.

RailGun v3

The next iteration of Railgun will reduce transaction costs by 50% to 60%.Other changes in version 3 are support for eip-4337 users, implemented through a dedicated memory pool.Additionally, v3 will support intent-based architectures that allow solutionists to compete for best execution, although details remain very high-level as of writing.They are currently working withCowSwapWorking together, plans to use front and rear hooks to allow resolvers to access funds.

Railgun Connect

Arguably the most interesting change in the proposal is a tool called Railgun Connect, which is similar to WalletConnect, allowing 0zk addresses to be connected to most front-ends for private use without these DApps explicitly providing integration with Railgun via custom modules.

Railgun Connect is a browser extension that actually uses the state of the HardHat locally to replicate the chain’s state and inject its own web3 provider into the DApp, with an RPC endpoint with a local HardHat version chain.This allows you to interact with a DApp contract as usual, record transactions, then batch it and create a snark proof and send it to the Railgun contract on the actual chain.Although this description is a little simpler, it conveys the overall idea.This allows you to interact with almost any DApp (there may be some edge cases for DApps that require extra off-link processing).It should be noted that the status of the local save chain is a resource-consuming operation, but once it is completed, you can use Railgun’s hidden address to interact with the DApp without any difference from using a normal wallet.

in conclusion

There are some interesting proposals for establishing hidden addresses in the Ethereum protocol.For example,IncoThe concept of an erc-20 “wrapper” is used, which encapsulates a normal erc-20 contract and encrypts all balances.Transfers and approvals are both performed in encrypted state via fully homomorphic encryption.Inco relies on precompilers that currently exist only on its own network, but may move to Ethereum in the future.

There is another proposal calledEIP-7503: Zero-Knowledge Wormholes, which is based on a design called “Proof of Burning”, although this proposal does not seem to have received much attention, probably because it requires an update to the EVM, without this update, it can only be implemented at the token level,Use an erc-20 design that specifically supports eip-7503 (or if an L2 decides to add support to its EVM opcode).

AztecProbably the most complex privacy technology at the moment, but it requires users to bridge funds to Aztec to use, which may not be acceptable to most users.However, if Ethereum users’ demand for basic transaction privacy grows, Aztec may have a unique value proposition to become a very valuable L2 as DApps and users migrate to a platform that provides privacy by default.

same,IntmaxIt is a privacy-centric Ethereum L2 (based on Plasma design), which also has a compliance regulatory aspect, verifying the legitimacy of individual funds through ZKP based on AML, and imposing restrictions on transaction amounts.Intmax has restrictions on providing privacy for money transfers, while EVM smart contract operations do not have privacy.However, unlike Aztec, smart contracts can be written in Solidity, which some developers may prefer (depending on the use case).

Wallet Support

While we are seeing an increase in adoption of hidden address protocols, which is a positive signal, there are still many challenges.The most important challenge is that they are not fully supported in mainstream Ethereum wallets (at least not yet).Mainstream wallets may need to make several choices when providing support for hidden addresses.These options include:

• Will they provide advocacy support for a single implementation, or will they build and maintain some kind of comprehensive aggregator across multiple protocols?The latter can be expensive in terms of development and maintenance.

• Will there be regulatory considerations and do we need to take a position on the scope and mechanism of selective deanonymity (such as the case of Labyrinth)?

• Hidden addresses require an on-chain component, through a registration contract (except Fluidkey), which means that each EVM network must be explicitly supported by the wallet (although Umbra’s design facilitates permissionless deployment of the registry).

• Hidden addresses make existing integration with block detectors such as Etherscan more complex.For example, the View on Detector button will not work for hiding meta addresses because the wallet shows aggregate balances.This problem may also exist in the transfer.These marginal cases need to be carefully considered.

• According to the underlying implementation, users can only effectively use hidden addresses with a specific set of DApps, i.e. those DApps supported by the underlying protocol.Modular hiding address architecture will make this possible.However, not all DApps will be supported and users need to be notified in some way.This is relatively easy when using eip-5506, but there are still complexity and edge cases that can penetrate into the user experience of your wallet.

There is room for improvement in preventing poor user privacy and hygiene, please refer to this article:Anonymity Analysis of the Umbra Stealth Address Scheme on Ethereum”, The author successfully deanonymous 48.5% of stealth transactions on the Ethereum mainnet. The heuristics they use are not protocol-related, but more about privacy sanitation, such as users sending funds to invisible addresses they control,These funds are then sent back to the initial sending address, incorrectly believing that traceability has been broken. Overall, the authors identified 6 different heuristics that can be used to deanonymize invisible address transactions, mainly based on theFollow best practices. However, these are key user experience issues that need to be addressed.

Overall, I’m pretty optimistic about invisible addresses and privacy in Ethereum.I think we made quite impressive progress and found some very remediaable challenges.I believe mainstream wallets will find ways to provide invisible address support so that users can easily use these addresses and enjoy the normal level of privacy that users expect and deserve.

Thanks to all the teams who have invested their time and hard work in researching and building invisible address infrastructure, including the four protocols I mentioned in this post.Their efforts and tenacity will have a huge impact on Ethereum!