{"id":36425,"date":"2019-10-31T22:11:34","date_gmt":"2019-10-31T19:11:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/konsensus-na-reputatsii-nody-nuzhen-li\/"},"modified":"2019-10-31T22:11:34","modified_gmt":"2019-10-31T19:11:34","slug":"konsensus-na-reputatsii-nody-nuzhen-li","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","title":{"rendered":"Konsens \u00fcber den Ruf eines Knotens. Braucht man das?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ich wei\u00df, ich wei\u00df. Es gibt unz\u00e4hlige Kryptoprojekte und jede Menge Konsensmodelle: auf Basis von Arbeit und Besitz, von Gold, \u00d6l oder sogar gebackenen Piroggen (ja, so etwas gibt es tats\u00e4chlich). Wozu also noch eines? Genau das m\u00f6chte ich nach der Lekt\u00fcre der \u00fcbersetzten \u201evereinfachten\u201c technischen Dokumentation des Projekts *Sternbild (Constellation<\/a><\/noindex>). Nat\u00fcrlich ist das keine vollst\u00e4ndige Beschreibung des Algorithmus, aber mich interessiert die Meinung der Habr-Community: Hat ein solcher Konsens eine Daseinsberechtigung oder braucht ihn eigentlich niemand?<\/p>\n

<\/p>\n

Weiter geht es mit nicht allzu viel Text. Wenn Sie also einfach nur schreiben m\u00f6chten \u201eIgitt, wie viel Krypto kann man noch bringen\u201c, dann bitte ich Sie, darauf zu verzichten. Wenn Sie neue Entwicklungen im Bereich verteilter Systeme spannend finden und in den Kommentaren etwas beizutragen haben, dann schauen Sie bitte unter den Cut.<\/p>\n

<\/p>\n

P.S. Ich bin nicht der Autor der Technologie und kann f\u00fcr eine vollst\u00e4ndige \u00dcbermittlung des Wesens nicht garantieren, daher freue ich mich \u00fcber Kommentare mit Korrekturen, falls welche kommen.<\/em><\/p>\n

<\/a><\/noindex><\/p>\n

Die Evolution von synchronen zu asynchronen Konsensmechanismen<\/h3>\n

<\/p>\n

Knoten werden mittels eines deterministischen Prozesses ausgew\u00e4hlt (derselbe, der auch in DHTs verwendet wird, zum Beispiel in BitTorrent), der dynamisch die Aufgaben der Knoten zur \"Erleichterung\" der Validierung regelt oder, was verst\u00e4ndlicher ist, um Konsens zu erreichen. Wir w\u00e4hlen Gruppen von 3 Knoten aus und f\u00fchren Konsensrunden parallel durch, sodass ein Knoten in mehreren Bl\u00f6cken als Facilitator fungieren kann. Dies erm\u00f6glicht es uns, Transaktionen asynchron zu verarbeiten, was im Wesentlichen bedeutet, dass mehrere Blockchains gleichzeitig erstellt werden. Dieser Prozess \u00e4hnelt einem Netz, das aus vielen F\u00e4den besteht, im Gegensatz zu Knoten, die im Laufe der Zeit eine einzige Kette bilden. Asynchrone oder parallele Verarbeitung sind die Grundlage skalierbaren Programmierens, da sie die Nutzung aller Computerressourcen erm\u00f6glicht und die Gesamtrechenleistung beschleunigt. Dieses Netzwerk wird als gerichteter azyklischer Graph oder DAG in der Informatik bezeichnet.<\/p>\n

<\/p>\n

\"Konsens
\nDie Bandbreite der linearen Blockchain im Vergleich zum multiplikativen Effekt des DAG, bei dem wir mehrere parallele Blockchains haben. <\/em><\/p>\n

<\/p>\n

\"Konsens
\nGeometrische Darstellung der linearen Blockchain gegen\u00fcber DAG. Schwarze Punkte sind Bl\u00f6cke, wei\u00dfe Punkte sind Knoten.<\/em><\/p>\n

<\/p>\n

Wir verwenden 3 Knoten in jedem Konsensus-Runde, da uns dies einige interessante mathematische Prozesse erm\u00f6glicht, um \u00fcber den Zustand nachzudenken, indem eine \"Oberfl\u00e4chenebene\" \u00fcber die Daten in Form von Dreiecken mit Verbindungen geformt wird. Dann nutzt das Protokoll die Dreiecke, um die optimale Fl\u00e4che \"zusammenzun\u00e4hen\", die keine \u00fcberfl\u00fcssigen oder widerspr\u00fcchlichen Daten enth\u00e4lt und so wenige Dreiecke wie m\u00f6glich hat. Algorithmisch entspricht dies einem \"minimalen Schnitt\" im Graphen, und mathematisch einer Ableitung oder Optimierungsfunktion (unter denen die Funktion den k\u00fcrzesten Weg findet, den sie \u00fcber die Fl\u00e4che kreuzen kann). Dieser k\u00fcrzeste Weg entspricht einer optimalen Speicherung von Daten (Transaktionen) in einer Gruppe von Datenbankverf\u00fcgbarkeiten. Konfligierende dreieckige \"Fliesen\", damit die Ereignisfl\u00e4che eben und konfliktfrei ist.<\/p>\n

<\/p>\n

\"Konsens
\nGeometrische Umsetzung der Konfliktentdeckung \/ -verarbeitung. Ein konfliktierender Block erzeugt eine zus\u00e4tzliche Oberfl\u00e4chenfliese. Wir entfernen die zus\u00e4tzliche Oberfl\u00e4chenfliese, um die Fl\u00e4che eben (= konfliktfrei) zu halten. <\/em><\/p>\n

<\/p>\n

Konsens, basierend auf Reputation<\/h3>\n

<\/p>\n

In einem optimalen dezentralisierten P2P-System f\u00fcr Reputation sollte jeder Knoten in der Lage sein, sein Vertrauen zu anderen Knoten unabh\u00e4ngig zu bestimmen. Unser System verwendet ein spezielles Modell, das transitive Beziehungen oder Beziehungen umfasst, die ein Knoten zu anderen Knoten hat, um eine globale Bewertung zuzuweisen. \"Du bist so gut wie dein Unternehmen.\" Das Endergebnis ist eine \"Verzerrung\" oder ein Gradient, der auf dem transitive Vertrauen oder Reputation aller Knoten in einem $DAG oder festgelegten Kanal basiert. Dies kann als eine Reibe oder ein K\u00e4sehobel angesehen werden, der \u00fcber die \"Oberfl\u00e4chenebene\" streicht und ausw\u00e4hlt, welche \"dreieckigen Fliesen\" wegzuwischen und welche zu belassen sind. So entfernt die Logik des Konflikts tats\u00e4chlich die \"dreieckigen Fliesen\".<\/p>\n

<\/p>\n

\"Konsens
\nDAG mit konfliktierender Fliese, die durch einen \"gekr\u00fcmmten\" Raum f\u00fchrt, der einem Gradient \u00e4hnlich wie ein K\u00e4sehobel ist und darauf abzielt, die konfliktierende Fliese zu entfernen oder zu \"l\u00f6schen\".<\/em><\/p>\n

<\/p>\n

Teilweise\/volle Skalierung des Knotens<\/h3>\n

<\/p>\n

In der Netzwerkteorie ist die optimale Verteilung in der Regel als \"ohne Skalierung\" bekannt, die als hierarchische Anordnung mit gro\u00dfen zentralen Knoten beschrieben werden kann, die viele kleinere periphere Knoten steuern. Diese Verteilung ist in der Natur zu sehen und vor allem im Internet. Constellation nutzt diese Architektur f\u00fcr das \"Skalieren\", also zur Erh\u00f6hung der Bandbreite oder Breite unseres Graphen.<\/p>\n

<\/p>\n

\"Konsens
\nEffekt der hierarchischen Zergliederung. Wir k\u00f6nnen weitere Knoten hinzuf\u00fcgen, wobei wir die Bandbreite erh\u00f6hen.<\/em><\/p>\n

<\/p>\n

Hylochain \u2013 Unterst\u00fctzung f\u00fcr kanalisierte Anwendungen.<\/h3>\n

<\/p>\n

Unser Ansatz zur Unterst\u00fctzung von Anwendungen kann als \"dezentrale Plattform f\u00fcr intelligente Vertr\u00e4ge\" betrachtet werden. Anstelle eines zentralen Netzwerks, das die gesamte Logik ausf\u00fchrt und alle Daten der Anwendung verarbeitet, koordiniert Constellation die Anwendungsdaten mit \"Staatskan\u00e4len\", die als Fernsehsender betrachtet werden k\u00f6nnen, die alle Daten aus dem staatlichen System \u00fcbertragen. Jeder Staatskanal kann seine eigene Pr\u00fcflogik implementieren, wodurch das Oracle-Problem durch Durchlaufpr\u00fcfung der Authentizit\u00e4t der Datenproduzenten und transitive Pr\u00fcfung der speziellen Staatsysteme gel\u00f6st wird. Netzwerke von Staatskan\u00e4len bieten parallele Unterst\u00fctzung f\u00fcr Anwendungen und verk\u00fcrzen die Entscheidungszeit, die in einem Netzwerk mit intelligenten Vertr\u00e4gen durch den traditionellen synchronen Konsens begrenzt ist.<\/p>\n

<\/p>\n

\"Konsens
\nZwei Staatskan\u00e4le, die \u00fcber das Netzwerk $DAG \"kompatibel\" sind. Sie k\u00f6nnen interagieren oder interpretiert werden, da sie beide mit $DAG durch den Einsatz hybrider $DAG + Kanal-Knoten \"integriert\" sind.<\/em><\/p>\n

<\/p>\n

Der Grund, warum es Hylochain genannt wird, liegt darin, dass wir in unserem Ansatz zur Unterst\u00fctzung von Anwendungen ein funktionales Programmiermodell namens Recursion Schemes verwendet haben, um eine MapReduce-Schnittstelle zu erstellen. Insbesondere k\u00f6nnen die Rekursionstypen Hylomorphismus und Metamorphismus integriert werden, um \u00fcberpr\u00fcfbare Anfragen und Streaming-Verbindungen \u00fcber Standardkan\u00e4le zu erstellen, indem algebraische Datentypen gepr\u00fcft werden, ebenso wie die op-Codes f\u00fcr Smart Contracts. Das Endergebnis ist eine funktionale MapReduce-Schnittstelle, die den Dateningenieuren vertraut ist und mit bestehender Big-Data-Technologie kompatibel ist.<\/p>\n

<\/p>\n

\"Konsens
\nHylomorphe und metamorphe Standardkan\u00e4le im Vergleich. Im metamorphosen Zustand werden die Daten aus zwei Standardkan\u00e4len in einem Block im Metakanal gesendet. Im Hilo nehmen wir den vorherigen Zustand des Kanals und verwenden ihn, um zwei andere Kan\u00e4le abzurufen (eine spezifische Frage zu stellen), und speichern dann das Ergebnis der Abfrage in einem Block.<\/em><\/p>\n

<\/p>\n

Tokenomics und ihre Verbindung zu Hylochain<\/h3>\n

<\/p>\n

Sobald der Standardkanal erstellt ist, kann er in den $DAG-Kanal integriert werden, jedoch mit der ACI- oder Application Chain Interface-Schnittstelle. Diese Schnittstelle ist einfach ein JSON-Objekt mit Konfigurationsinformationen und einem \u00f6ffentlichen Schl\u00fcssel, der mit dem Kanal selbst verbunden ist. Der Grund, warum wir den \u00f6ffentlichen Schl\u00fcssel mit dem Standardkanal verkn\u00fcpfen, besteht darin, einen Broker-Mechanismus f\u00fcr die Daten des Standardkanals zu schaffen. Wenn der Standardkanal bereitgestellt wird, konfigurieren die Entwickler selbst, wie die Zahlungen aus dem $DAG-Netzwerk zwischen Knoten und Betreibern verteilt werden.<\/p>\n

<\/p>\n

\"Konsens
\nEin Stream zum Kauf von Zugriff auf Informationen oder zur Modifikation von Informationen. Die Anfrage wird an den $DAG gesendet, die Mittel werden auf das Konto des Kanals \u00fcberwiesen, das Ergebnis wird an den K\u00e4ufer gesendet, und die Pr\u00fcfziffer der Transaktion wird an das $DAG-Netzwerk gesendet, das dann die Mittel f\u00fcr den Standardkanal freigibt.<\/em><\/p>\n

Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0417\u043d\u0430\u044e-\u0437\u043d\u0430\u044e. \u041a\u0440\u0438\u043f\u0442\u043e\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0442\u044c\u043c\u0430, \u0435\u0441\u0442\u044c \u043a\u0443\u0447\u0430 \u043a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441\u043e\u0432: \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0442\u0440\u0443\u0434\u0430 \u0438 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u044f, \u0437\u043e\u043b\u043e\u0442\u0430, \u043d\u0435\u0444\u0442\u0438, \u0432\u044b\u043f\u0435\u0447\u0435\u043d\u043d\u044b\u0445 \u043f\u0438\u0440\u043e\u0436\u043a\u043e\u0432 (\u0435\u0441\u0442\u044c \u0438 \u0442\u0430\u043a\u043e\u0439, \u0434\u0430-\u0434\u0430). \u0427\u0442\u043e \u043d\u0430\u043c \u0435\u0449\u0451 \u043e\u0442 \u043e\u0434\u043d\u043e\u0433\u043e? \u042d\u0442\u043e \u0438 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0431\u0441\u0443\u0434\u0438\u0442\u044c \u043f\u043e\u0441\u043b\u0435 \u043f\u0440\u043e\u0447\u0442\u0435\u043d\u0438\u044f \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0430 «\u043e\u0431\u043b\u0435\u0433\u0447\u0435\u043d\u043d\u043e\u0439» \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 *\u0421\u043e\u0437\u0432\u0435\u0437\u0434\u0438\u0435 (Constellation). \u041a\u043e\u043d\u0435\u0447\u043d\u043e, \u044d\u0442\u043e \u043d\u0435 \u043f\u043e\u043b\u043d\u043e\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u0430, \u043d\u043e \u043c\u043d\u0435 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u043c\u043d\u0435\u043d\u0438\u0435 \u043a\u043e\u043c\u044c\u044e\u043d\u0438\u0442\u0438 \u0445\u0430\u0431\u0440\u0430, \u0438\u043c\u0435\u0435\u0442 \u043b\u0438 \u043c\u0435\u0441\u0442\u043e «\u0431\u044b\u0442\u044c» \u0442\u0430\u043a\u043e\u043c\u0443 \u043a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441\u0443 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27262,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36425","post","type-post","status-publish","format-standard","has-post-thumbnail","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\udd47Konsens der Knotenreputation. Brauchen wir das?","description":"Ich wei\u00df, ich wei\u00df. Es gibt unz\u00e4hlige Krypto-Projekte, eine Menge Konsensarten: basierend auf Arbeit und Besitz, Gold, \u00d6l, gebackenen Pasteten (ja, sogar das). Was brauchen wir noch von einem?","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\u041a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441 \u043d\u0430 \u0440\u0435\u043f\u0443\u0442\u0430\u0446\u0438\u0438 \u043d\u043e\u0434\u044b. \u041d\u0443\u0436\u0435\u043d \u043b\u0438? | ProHoster","og:description":"\u0417\u043d\u0430\u044e-\u0437\u043d\u0430\u044e. \u041a\u0440\u0438\u043f\u0442\u043e\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u0442\u044c\u043c\u0430, \u0435\u0441\u0442\u044c \u043a\u0443\u0447\u0430 \u043a\u043e\u043d\u0441\u0435\u043d\u0441\u0443\u0441\u043e\u0432: \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0442\u0440\u0443\u0434\u0430 \u0438 \u0432\u043b\u0430\u0434\u0435\u043d\u0438\u044f, \u0437\u043e\u043b\u043e\u0442\u0430, \u043d\u0435\u0444\u0442\u0438, \u0432\u044b\u043f\u0435\u0447\u0435\u043d\u043d\u044b\u0445 \u043f\u0438\u0440\u043e\u0436\u043a\u043e\u0432 (\u0435\u0441\u0442\u044c \u0438 \u0442\u0430\u043a\u043e\u0439, \u0434\u0430-\u0434\u0430). \u0427\u0442\u043e \u043d\u0430\u043c \u0435\u0449\u0451 \u043e\u0442 \u043e\u0434\u043d\u043e\u0433\u043e?","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/konsensus-na-reputatsii-nody-nuzhen-li","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-31T19:11:34+00:00","article:modified_time":"2019-10-31T19:11:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36425","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-22 03:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:45:35","updated":"2026-01-22 03:15:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/36425","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=36425"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/36425\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/27262"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=36425"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=36425"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=36425"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}