{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Willekeurige getallen en gedecentraliseerde netwerken: implementaties","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Inleiding<\/h1>\n

<\/p>\n

functie getAbsoluutWillekeurigNummer() {\n        return 4; \/\/ retourneert absoluut willekeurig nummer!\n}<\/code><\/pre>\n
<\/p>\n
Net als bij het concept van een absoluut veilig cipher in de cryptografie, proberen echte protocollen 'Publicly Verifiable Random Beacon' (hierna PVRB) slechts zo dicht mogelijk bij het ideale schema te komen, omdat het in echte netwerken in pure vorm niet toepasbaar is: men moet het strikt eens zijn over \u00e9\u00e9n bit, er moeten veel rondes zijn en alle berichten moeten ideaal snel zijn en altijd worden afgeleverd. Uiteraard is dit niet het geval in echte netwerken. Daarom, bij het ontwerpen van PVRB voor specifieke taken in moderne blockchains, nemen we naast de onmogelijkheid om de verkregen randomisatie en cryptografische veiligheid te controleren, ook veel puur architectonische en technische problemen in overweging.<\/p>\n
<\/a><\/noindex><\/p>\n
De blockchain zelf fungeert voor PVRB in wezen als een communicatiemiddel, waarbij berichten = transacties zijn. Dit maakt het mogelijk om gedeeltelijk abstract te zijn van netwerkproblemen, het niet afleveren van berichten en problemen met tussensoftware \u2014 al deze risico\u2019s worden gedragen door het gedecentraliseerde netwerk, en de belangrijkste waarde ervan voor PVRB is de onmogelijkheid om een al verzonden transactie in te trekken of te bederven \u2014 dit voorkomt dat deelnemers zich terugtrekken uit het protocol, tenzij ze een succesvolle aanval op de consensus hebben uitgevoerd. Dit niveau van veiligheid is aanvaardbaar, daarom moet PVRB bestand zijn tegen samenspanning van deelnemers in dezelfde mate als de hoofdblockchain. Dit suggereert ook dat PVRB een deel van de consensus moet zijn, als het netwerk het eens is over de hoofdblockchain, evenzo moet het een eerlijke resulterende randomisatie overeenkomen. Of, PVRB is gewoon een standalone protocol, uitgevoerd door een slimme contract, dat asynchroon werkt ten opzichte van de blockchain en de blokken. Beide manieren hebben hun eigen voor- en nadelen, en de keuze tussen hen is uiterst niet-triviaal. <\/p>\n
<\/p>\n
Twee manieren om PVRB te implementeren<\/h2>\n
<\/p>\n
Laten we dieper ingaan op de twee varianten van PVRB-implementatie: de standalone versie, die werkt met behulp van een onafhankelijk slim contract van de blockchain, en de consensus-ge\u00efntegreerde versie \u2014 ingebed in het protocol, volgens welk het netwerk overeenstemming bereikt over de blokketen en de inbegrepen transacties. In alle gevallen zal ik de populaire blockchain-engines in gedachten hebben: Ethereum, EOS, en alle gelijken met betrekking tot plaatsing en verwerking van slimme contracten. <\/p>\n
<\/p>\n
Standalone contract<\/h3>\n
<\/p>\n
In deze variant is PVRB een slim contract dat transacties van random producers (hierna RP) accepteert, deze verwerkt, resultaten combineert en uiteindelijk tot een waarde komt die elke gebruiker uit dit contract kan verkrijgen. Deze waarde hoeft niet rechtstreeks in het contract te worden opgeslagen, maar kan alleen worden vertegenwoordigd door gegevens waaruit op deterministische wijze \u00e9\u00e9n en slechts \u00e9\u00e9n waarde van de resulterende random kan worden verkregen. In dit schema zijn RP gebruikers van de blockchain, en iedereen kan deelnemen aan het generatieproces.<\/p>\n
<\/p>\n
De standalone-contract variant heeft voordelen:<\/p>\n
<\/p>\n