{"id":34101,"date":"2019-10-31T21:56:25","date_gmt":"2019-10-31T18:56:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ob-anonimnosti-v-account-based-blokchejnah\/"},"modified":"2019-10-31T21:56:25","modified_gmt":"2019-10-31T18:56:25","slug":"ob-anonimnosti-v-account-based-blokchejnah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","title":{"rendered":"On Anonymity in Account-Based Blockchains","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

We have been interested in the topic of anonymity in cryptocurrencies for quite some time and are keenly following developments in this area. In our articles, we have already delved into the principles of operation of confidential transactions<\/a><\/noindex> in Monero, and have also conducted comparative review<\/a><\/noindex> research on technologies existing in this field. However, all anonymous cryptocurrencies today are built on the data model proposed by Bitcoin \u2014 Unspent Transaction Output (UTXO). For account-based blockchains like Ethereum, existing solutions for implementing anonymity and privacy (for example, Mobius<\/a><\/noindex> or Aztec<\/a><\/noindex>) have tried to replicate the UTXO model in smart contracts.<\/p>\n

In February 2019, a group of researchers from Stanford University and Visa Research<\/a><\/noindex> was released released a preprint<\/a><\/noindex> titled \"Zether: Towards Privacy in Smart Contracts\". The authors proposed an approach for ensuring anonymity in account-based blockchains for the first time and presented two types of smart contracts: for confidential (hiding balances and transaction amounts) and anonymous (hiding recipient and sender) transactions. We find the proposed technology interesting and would like to share its structure, as well as discuss why the issue of anonymity in account-based blockchains is considered very complex and whether the authors have fully resolved it.<\/p>\n

On the structure of these data models<\/h3>\n

\nIn the UTXO model, a transaction consists of 'inputs' and 'outputs'. The direct analogy to 'outputs' is the bills in your wallet: each 'output' has a certain denomination. When you pay someone (create a transaction), you spend one or more 'outputs', which then become 'inputs' of the transaction, and the blockchain marks them as spent. Meanwhile, the recipient of your payment (or yourself if you require change) receives newly generated 'outputs'. This can be visually represented as follows:<\/p>\n

\"On
\n
\nAccount-based blockchains operate similarly to your bank account. They only deal with the amount in your account and the transaction amount. When you transfer a certain amount from your account, you do not burn any 'outputs'; the network does not need to remember which coins have been spent and which have not. In the simplest case, verifying a transaction boils down to checking the sender's signature and the amount in their balance:<\/p>\n

\"On
\n<\/p>\n

Analysis of the technology<\/h3>\n

\nNext, we will discuss how Zether conceals the amount of transactions, the recipient, and the sender. Throughout the description of its operating principles, we will note the differences between confidential and anonymous versions. Since ensuring confidentiality in account-based blockchains is much simpler, some of the limitations imposed by anonymization will be irrelevant for the confidential version of the technology.<\/p>\n

Concealing balances and transaction amounts<\/h4>\n

\nFor encrypting balances and transaction amounts in Zether, an encryption scheme is used of ElGamal.<\/a><\/noindex>It works as follows. When Alice wants to send Bob b<\/b><\/i> coins to an address (his public key), Y<\/b><\/i>she chooses a random number r<\/b><\/i> and encrypts the amount:<\/p>\n

\"On
\nwhere C<\/b><\/i> \u2014 the encrypted amount, D<\/b><\/i> \u2014 an auxiliary value needed to decrypt this amount, G<\/b><\/i> \u2014 a fixed point on the elliptic curve, from which the public key is derived by multiplying the secret key.<\/p>\n

When Bob receives these values, he simply adds them to his similarly encrypted balance, which makes this scheme convenient.<\/p>\n

Similarly, Alice subtracts the same values from her balance, just using her public key as Y<\/b><\/i> an input.<\/p>\n

Concealing the recipient and sender<\/h4>\n

\nMixing \u2018outputs\u2019 in UTXO originated early in the history of cryptocurrencies and helps conceal the sender. To do this, the sender, when making a transfer, selects random \u2018outputs\u2019 from the blockchain and mixes them with their own. Then they sign the \u2018outputs\u2019 using a ring signature\u2014a cryptographic mechanism that allows the verifier to be convinced that among the mixed \u2018outputs\u2019 are coins belonging to the sender. The mixed coins, of course, are not spent.<\/p>\n

However, to conceal the recipient, we cannot generate false \u2018outputs\u2019. Therefore, in UTXO, each \u2018output\u2019 has its own unique address, which is cryptographically linked to the address of the recipient of these coins. Currently, there is no way to identify the connection between the unique \u2018output\u2019 address and the recipient's address without knowing their secret keys.<\/p>\n

In the account-based model, we cannot use one-time addresses (otherwise it would be the 'outputs' model). Therefore, the sender and receiver must be mixed among other accounts on the blockchain. At the same time, an encrypted 0 coins are deducted from the mixed accounts (or added 0 \u2014 in the case of mixing the receiver), effectively not changing their actual balance.<\/p>\n

Since both the sender and the receiver always have a permanent address, there is a need to use the same groups for mixing when transferring to the same addresses. This is easier to illustrate with an example.<\/p>\n

Suppose Alice decided to make a donation to Bob's charity but prefers to keep this transfer anonymous from external observers. To disguise herself in the sender field, she includes Adam and Adele\u2019s accounts. To hide Bob, she additionally includes Ben and Bill in the receiver field. For her next contribution, Alice decided to include Alex and Amanda next to herself, and Bruce and Benjen next to Bob. In this case, when analyzing the blockchain, there will be just one intersecting pair of participants in these two transactions \u2014 Alice and Bob, which deanonymizes these transactions.<\/p>\n

\"On
\n<\/p>\n

Transaction Races<\/h4>\n

\nAs we mentioned, to conceal their balance in account-based systems, the user encrypts their balance and the transfer amount. They must prove that the balance in their account remains non-negative. The problem is that, when forming a transaction, the user constructs a proof regarding their current account state. But what if Bob sends a transaction to Alice, and it is accepted before Alice's transaction? Then Alice's transaction will be considered invalid, since the balance proof was built before Bob's transaction was accepted.<\/p>\n

\"On
\n
\nThe first solution that comes to mind in such a situation is to freeze the account until the transaction is completed. However, this approach is not suitable, as aside from the complexity of solving such a task in a distributed system, it will be unclear in an anonymous scheme which account to block.<\/p>\n

To address this issue, the technology separates incoming and outgoing transactions: spending has an immediate effect on the balance, while income is delayed. This introduces the concept of an 'epoch' \u2014 a group of fixed-size blocks. The current 'epoch' is determined by dividing the block height by the group size. When processing a transaction, the network updates the sender's balance immediately, while the recipient's funds are held in a vault. The accumulated funds are accessible to the payment recipient only upon the onset of a new 'epoch.'<\/p>\n

As a result, users can send transactions regardless of how frequently they receive funds (as long as their balance permits, of course). The size of the epoch is determined by how quickly blocks propagate through the network and how swiftly a transaction is included in a block. <\/p>\n

This solution works well for confidential transfers; however, with anonymous transactions, as we will see later, it creates serious issues.<\/p>\n

Protection against replay attacks<\/h4>\n

\nIn account-based blockchains, each transaction is signed with the sender's private key, which assures the verifier that the transaction has not been altered and was generated by the owner of that key. But what if an attacker intercepting the transmission channel captures this message and sends an identical duplicate? The verifier will check the transaction's signature and will be convinced of its authenticity, and the network will deduct the same amount from the sender's balance again.<\/p>\n

This type of attack is called a replay attack. In the UTXO model, such attacks are not relevant, as the attacker will attempt to use spent outputs, which is invalid in itself and rejected by the network.<\/p>\n

To prevent this, a field containing random data is embedded in the transaction, referred to as a nonce or simply 'salt.' When resending a transaction with 'salt,' the verifier checks whether this nonce has been used previously, and if not, considers the transaction valid. To avoid storing the entire history of nonces of users in the blockchain, it is typically set to zero in the very first transaction, and incremented by one thereafter. The network only needs to verify that the nonce of the new transaction is different from the previous one by one.<\/p>\n

In an anonymous transaction scheme, the problem of validating nonces arises. We cannot explicitly bind the nonce to the sender's address, as this would obviously de-anonymize the transaction. We also cannot increment the nonces of all involved accounts, as this may conflict with other transactions that are being processed. <\/p>\n

The authors of Zether propose to generate nonces cryptographically\u2014depending on the \"epoch.\" For example:<\/p>\n

\"On
\nHere x<\/i><\/b> \u2014 the sender's secret key, and Gepoch<\/i><\/b> \u2014 an additional generator for epochs, obtained by hashing a string of the form 'Zether + '. Now, it seems the problem is solved \u2014 we do not reveal the sender's nonce and do not interfere with the nonces of uninvolved participants. However, this approach imposes a serious limitation: a single account can send no more than one transaction per 'epoch'. Unfortunately, this issue remains unresolved and currently renders the anonymous version of Zether, in our opinion, hardly usable.<\/p>\n

Zero-knowledge proof complexity<\/h4>\n

\nIn UTXO, the sender must prove to the network that they are not spending a negative amount; otherwise, the generation of new coins from thin air becomes possible (we wrote about why this is possible in one of the previous articles). They must also sign the \"inputs\" with a ring signature to prove that among the mixed coins, there are funds belonging to them. articles<\/a><\/noindex>)<\/p>\n

In the anonymous version of the account-based blockchain, the expressions for proof become much more complex. The sender proves that:<\/p>\n

    \n
  1. The amount sent is positive;<\/li>\n
  2. The balance remains non-negative;<\/li>\n
  3. The sender has correctly encrypted the transfer amounts (including zeroes);<\/li>\n
  4. The balance is changed only for the sender and the recipient;<\/li>\n
  5. The sender owns the secret key for their account, and it is indeed present in the list of senders (among the mixed participants);<\/li>\n
  6. The nonce used in the transaction is constructed correctly.<\/li>\n<\/ol>\n

    \nFor such complex proofs, the authors use a mixture of Bulletproof<\/a><\/noindex> (one of the authors, by the way, participated in its creation) and Sigma protocol<\/a><\/noindex>, which they call Sigma-bullets. The formal proof of such a statement is quite a challenging task, and it greatly limits the number of those willing to implement the technology.<\/p>\n

    What\u2019s the result?<\/h4>\n

    \nIn our opinion, the part of Zether that introduces privacy to account-based blockchains could be used right now. However, at the moment, the anonymous version of the technology imposes serious limitations on its use, and its complexity affects implementation. However, we shouldn't forget that the authors released it only a few months ago, and perhaps someone else will find a solution to the existing problems. After all, that's how science progresses.
    \n
    Source:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u043c\u044b \u0443\u0436\u0435 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u043b\u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043a\u043e\u043d\u0444\u0438\u0434\u0435\u043d\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u0445 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0439 \u0432 Monero, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043f\u0440\u043e\u0432\u043e\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043e\u0431\u0437\u043e\u0440 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439, \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043d\u0430 \u044d\u0442\u043e\u043c \u043f\u043e\u043b\u0435. \u041e\u0434\u043d\u0430\u043a\u043e \u0436\u0435 \u0432\u0441\u0435 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u044b\u0435 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u044b \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u044b \u043d\u0430 \u043c\u043e\u0434\u0435\u043b\u0438 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u043d\u043e\u0439 Bitcoin \u2014 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34101","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 About Anonymity in Account-Based Blockchains | ProHoster","description":"We have long been interested in the topic of anonymity in cryptocurrencies and strive to keep up with the development of technologies in this area.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 account-based \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430\u0445 | ProHoster","og:description":"\u041c\u044b \u0443\u0436\u0435 \u0434\u0430\u0432\u043d\u043e \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u0443\u0435\u043c\u0441\u044f \u0442\u0435\u043c\u043e\u0439 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u043e\u0441\u0442\u0438 \u0432 \u043a\u0440\u0438\u043f\u0442\u043e\u0432\u0430\u043b\u044e\u0442\u0430\u0445 \u0438 \u0441\u0442\u0430\u0440\u0430\u0435\u043c\u0441\u044f \u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0435\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u044d\u0442\u043e\u0439 \u043e\u0431\u043b\u0430\u0441\u0442\u0438.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:56:25+00:00","article:modified_time":"2019-10-31T18:56:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34101","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 17:56:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:28:34","updated":"2026-01-21 17:56:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/34101","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=34101"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/34101\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=34101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=34101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=34101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}