{"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\/nl\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","title":{"rendered":"Over anonimiteit in account-gebaseerde blockchains","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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. In our articles, we have already explored the principles of operation in detail. confidential transactions<\/a><\/noindex> in Monero, as well as conducted a comparative review<\/a><\/noindex> of the technologies that exist 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 confidentiality (such as Mobius<\/a><\/noindex> of Aztec<\/a><\/noindex>) have attempted 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> uitgebracht published a preprint<\/a><\/noindex> entitled 'Zether: Towards Privacy in the World of Smart Contracts'. The authors were the first to propose an approach for ensuring anonymity in account-based blockchains and presented two variants of smart contracts: for confidential (hiding balances and amounts of transfers) and anonymous (hiding the sender and receiver) 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'. A direct analogy for the 'outputs' is the banknotes in your wallet: each 'output' has a certain denomination. When you pay someone (create a transaction), you spend one or more 'outputs', which become the 'inputs' of the transaction, and the blockchain marks them as spent. The recipient of your payment (or you, if you need change) receives newly generated 'outputs'. This can be schematically represented as follows:<\/p>\n

\"Over
\n
\nAccount-based blockchains are structured somewhat like your bank account. They operate solely on the amount in your account and the amount being transferred. When you transfer an amount from your account, you do not burn any 'outputs', and the network does not need to remember which coins have been spent and which have not. In its simplest form, transaction verification boils down to checking the sender's signature and the amount in their balance:<\/p>\n

\"Over
\n<\/p>\n

Analysis of the technology<\/h3>\n

\nLaten we nu bespreken hoe Zether het bedrag van transacties, de ontvanger en de afzender verbergt. Tijdens de beschrijving van de werking ervan zullen we de verschillen in vertrouwelijkheid en anonimiteit markeren. Aangezien het veel eenvoudiger is om vertrouwelijkheid te waarborgen in account-gebaseerde blockchains, zullen sommige van de beperkingen die door anonimiteit worden opgelegd, niet relevant zijn voor de vertrouwelijke versie van de technologie.<\/p>\n

Verbergen van saldi en transactiebedragen<\/h4>\n

\nVoor het versleutelen van saldi en transactiebedragen in Zether wordt een versleutelingsschema gebruikt van ElGamal.<\/a><\/noindex>Het werkt als volgt. Wanneer Alice Bob b<\/b><\/i> een aantal munten naar (zijn publieke sleutel) wil sturen, Y<\/b><\/i>kiest ze een willekeurig getal , die de eerste regel van het verzoek, de headers en de gegevens scheidt.<\/b><\/i> en versleutelt ze het bedrag:<\/p>\n

\"Over
\nwaar C<\/b><\/i> \u2014 het versleutelde bedrag, D<\/b><\/i> \u2014 een hulpparameter die nodig is voor het ontsleutelen van dit bedrag, G<\/b><\/i> \u2014 een vast punt op de elliptische kromme, waarbij de publieke sleutel verkregen wordt door de geheime sleutel ermee te vermenigvuldigen.<\/p>\n

Wanneer Bob deze waarden ontvangt, voegt hij ze eenvoudigweg toe aan zijn op dezelfde manier versleutelde saldo, wat het schema handig maakt.<\/p>\n

Op dezelfde manier trekt Alice dergelijke waarden af van haar saldo, maar gebruikt ze als Y<\/b><\/i> haar publieke sleutel.<\/p>\n

Het verbergen van de ontvanger en afzender<\/h4>\n

\nHet mengen van 'uitgangen' in UTXO is al ontstaan in de vroege dagen van cryptocurrency en helpt de afzender te verbergen. Hiervoor selecteert de afzender bij het uitvoeren van een transactie willekeurige 'uitgangen' in de blockchain en mengt deze met zijn eigen. Vervolgens ondertekent hij de 'uitgangen' met een ringhandtekening \u2014 een cryptografisch mechanisme dat de controleur overtuigt dat onder de gemengde 'uitgangen' munten van de afzender aanwezig zijn. De gemengde munten worden uiteraard niet uitgegeven.<\/p>\n

Echter, om de ontvanger te verbergen, kunnen we geen valse 'uitgangen' genereren. Daarom heeft elke 'uitgang' in UTXO zijn unieke adres, dat cryptografisch is verbonden met het adres van de ontvanger van deze munten. Tot nu toe is er geen manier om de verbinding tussen het unieke adres van de 'uitgang' en het adres van de ontvanger te onthullen zonder zijn geheime sleutels te kennen.<\/p>\n

In een account-based model kunnen we geen eenmalige adressen gebruiken (anders zou het al een 'uitgangs'-model zijn). Daarom moeten zowel de ontvanger als de afzender worden vermengd tussen andere accounts in de blockchain. Hierbij wordt van de vermengde accounts een gecodeerde 0 munt afgeschreven (of 0 toegevoegd \u2014 in het geval van het vermengen van de ontvanger), waardoor hun werkelijke balans feitelijk niet verandert.<\/p>\n

Aangezien zowel de afzender als de ontvanger altijd een vast adres hebben, is het hier noodzakelijk om bij overboekingen naar dezelfde adressen dezelfde groepen voor het vermengen te gebruiken. Het is makkelijker om dit aan de hand van een voorbeeld te bekijken.<\/p>\n

Stel dat Alice heeft besloten een donatie te doen aan Bob's liefdadigheidsinstelling, maar ze geeft er de voorkeur aan dat deze overdracht anoniem blijft voor een externe waarnemer. Om zichzelf in het afzenderveld te maskeren, schrijft ze ook de accounts van Adam en Adele erbij. En om Bob te verbergen \u2014 in het ontvanger veld voegt ze bovendien de accounts van Ben en Bill toe. Bij de volgende donatie besloot Alice Alex en Amanda naast zich te schrijven, en naast Bob Bruce en Benjen. In dit geval zal bij de analyse van de blockchain in deze twee transacties slechts \u00e9\u00e9n overlappend paar deelnemers worden gevonden \u2014 Alice en Bob, wat deze transacties de-anonimiseert.<\/p>\n

\"Over
\n<\/p>\n

Transactie races<\/h4>\n

\nZoals we al hebben vermeld, verbergt een gebruiker in account-based systemen zijn saldo en het over te maken bedrag. Hierbij moet hij bewijzen dat het saldo op zijn rekening niet negatief blijft. Het probleem is dat wanneer de gebruiker een transactie opzet, hij een bewijs opbouwt omtrent zijn huidige rekeningstatus. Maar wat als Bob een transactie naar Alice stuurt, en deze wordt eerder geaccepteerd dan die van Alice? Dan wordt de transactie van Alice als ongeldig beschouwd, omdat het bewijs van het saldo v\u00f3\u00f3r de acceptatie van Bobs transactie is opgebouwd.<\/p>\n

\"Over
\n
\nDe eerste oplossing die in een dergelijke situatie opkomt, is om het account te bevriezen totdat de transactie is uitgevoerd. Maar deze aanpak is niet geschikt, omdat, naast de complexiteit van het oplossen van een dergelijke taak in een gedistribueerd systeem, het in een anoniem systeem niet duidelijk is wiens account geblokkeerd moet worden.<\/p>\n

Om dit probleem op te lossen, deelt de technologie inkomende en uitgaande transacties: het uitgeven van middelen heeft een onmiddellijke impact op de balans, terwijl inkomsten uitgesteld zijn. Hiervoor wordt het concept 'tijdperk' ge\u00efntroduceerd \u2014 een groep blokken van vaste grootte. Het huidige 'tijdperk' wordt bepaald door de hoogte van het blok te delen door de groepsgrootte. Bij het verwerken van een transactie werkt het netwerk de balans van de afzender onmiddellijk bij, terwijl de middelen van de ontvanger in een reserve worden geplaatst. De verzamelde middelen worden pas ter beschikking van de ontvanger gesteld bij het begin van een nieuw 'tijdperk'.<\/p>\n

Hierdoor kan de gebruiker transacties verzenden, ongeacht hoe vaak hij middelen ontvangt (voor zover zijn balans dat toelaat, natuurlijk). De grootte van het tijdperk wordt bepaald aan de hand van hoe snel blokken zich door het netwerk verspreiden en hoe snel een transactie in een blok komt. <\/p>\n

Deze oplossing werkt goed voor vertrouwelijke overmakingen, maar met anonieme transacties, zoals we later zullen zien, cre\u00ebert dit serieuze problemen.<\/p>\n

Bescherming tegen replay-aanvallen<\/h4>\n

\nIn account-based blockchains wordt elke transactie ondertekend met de priv\u00e9-sleutel van de afzender, wat de controleur verzekert dat de transactie niet is gewijzigd en is gemaakt door de eigenaar van die sleutel. Maar wat als een kwaadwillende, die de communicatie afluistert, dit bericht opvangt en een exactzelfde bericht opnieuw verzendt? De controleur controleert de handtekening van de transactie en is overtuigd van de authenticiteit, en het netwerk haalt hetzelfde bedrag opnieuw van de balans van de afzender af.<\/p>\n

Deze aanval wordt een replay-aanval genoemd. In het UTXO-model zijn dergelijke aanvallen niet relevant, aangezien de aanvaller zal proberen gebruikte uitgangen te gebruiken, wat op zichzelf ongeldig is en door het netwerk wordt afgewezen.<\/p>\n

Om te voorkomen dat dit gebeurt, wordt er een veld met willekeurige gegevens in de transactie ingebouwd, dat nonce of gewoon 'zout' wordt genoemd. Bij het opnieuw verzenden van de transactie met 'zout' controleert de controleur of deze nonce eerder is gebruikt en, indien niet, beschouwt hij deze transactie als geldig. Om niet de volledige geschiedenis van gebruikers' nonces in de blockchain op te slaan, wordt bij de allereerste transactie meestal aangenomen dat deze gelijk is aan nul, en daarna met \u00e9\u00e9n verhoogd. Het netwerk hoeft alleen maar te controleren of de nonce van de nieuwe transactie verschilt van de vorige met \u00e9\u00e9n.<\/p>\n

In an anonymous transfer scheme, the problem of validating transaction nonces arises. We cannot directly bind the nonce to the sender's address, as this would obviously deanonymize the transfer. We also cannot increment the nonces of all involved accounts, as this might conflict with other transfers currently being processed. <\/p>\n

The authors of Zether suggest generating nonces cryptographically \u2014 depending on the 'epoch'. For example:<\/p>\n

\"Over
\nHier x<\/i><\/b> \u2014 the sender's secret key, and Gepoch<\/i><\/b> \u2014 een aanvullende generator voor een epoch, verkregen door een string te hashgeschreven zoals 'Zether + '. Nu lijkt het probleem opgelost \u2014 we onthullen niet de nonce van de verzender en bemoeien ons niet met de nonces van niet-betrokken deelnemers. Maar deze aanpak legt een ernstige beperking op: \u00e9\u00e9n account kan niet meer dan \u00e9\u00e9n transactie in een 'epoch' verzenden. Dit probleem blijft helaas onopgelost en maakt de anonieme versie van Zether, in onze ogen, nauwelijks bruikbaar.<\/p>\n

Zero-Knowledge Proofs<\/h4>\n

\nIn UTXO, the sender must prove to the network that they are not spending a negative amount, otherwise, it would be possible to generate new coins out of thin air (why this is possible has been discussed in one of the previous artikelen<\/a><\/noindex>). They must also sign the 'inputs' with a ring signature to prove that among the mixed coins, there are funds belonging to them.<\/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 amounts of transfers (including zero);<\/li>\n
  4. The balance changes only for the sender and the receiver;<\/li>\n
  5. The sender possesses the secret key to their account and that they are indeed on the list of senders (among the mixed);<\/li>\n
  6. The nonce used in the transaction is composed correctly.<\/li>\n<\/ol>\n

    \nFor such a complex proof, the authors use a mix Kogelvrij<\/a><\/noindex> (one of the authors participated in its creation) and Sigma protocol<\/a><\/noindex>, which is referred to as Sigma-bullets. The formal proof of such a claim is quite a complex task and greatly limits the number of those willing to implement the technology.<\/p>\n

    Wat is het resultaat?<\/h4>\n

    \nNaar onze mening kan de Zether-component, die privacy toevoegt aan account-based blockchains, nu al gebruikt worden. Maar op dit moment legt de anonieme versie van de technologie ernstige beperkingen op aan het gebruik, en de complexiteit ervan aan de implementatie. Toch moet men niet vergeten dat de auteurs het pas een paar maanden geleden hebben uitgebracht, en misschien vindt iemand anders wel een oplossing voor de huidige problemen. Dit is tenslotte hoe wetenschap werkt.
    \n
    Bron:     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\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\udd47Over anonimiteit in account-based blockchains | ProHoster","description":"We zijn al een tijdje ge\u00efnteresseerd in de kwestie van anonimiteit in cryptocurrencies en proberen de ontwikkelingen op dit gebied te volgen.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ob-anonimnosti-v-account-based-blokchejnah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/34101","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=34101"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34101\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=34101"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=34101"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=34101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}