Einführung

function getAbsolutelyRandomNumer() { return 4; // returns absolutely random number! } 

Wie im Fall des Konzepts einer absolut sicheren Kryptographie-Verschlüsselung versuchen die echten öffentlich verifizierbaren Random Beacon-Protokolle (im Folgenden: PVRB) nur, dem idealen Schema so nahe wie möglich zu kommen. In realen Netzwerken in seiner reinen Form ist es nicht anwendbar: Es ist notwendig, sich strikt auf ein Bit zu einigen, es sollte viele Runden geben und alle Nachrichten sollten perfekt schnell sein und immer zugestellt werden. In realen Netzwerken ist dies natürlich nicht der Fall. Daher treten beim Entwerfen von PVRB für bestimmte Aufgaben in modernen Blockchains neben der Unfähigkeit, die resultierende Zufälligkeit und kryptografische Stärke zu steuern, viele rein architektonische und technische Probleme auf.

Die Blockchain selbst ist für PVRB im Wesentlichen ein Kommunikationsmedium, in dem Nachrichten = Transaktionen sind. Auf diese Weise können Sie Netzwerkprobleme, Nachrichtenübermittlung und Middleware-Probleme teilweise ignorieren. All diese Risiken werden von einem dezentralen Netzwerk getragen. Der Hauptwert für PVRB ist die Unfähigkeit, eine bereits gesendete Transaktion zurückzuziehen oder zu ruinieren. Dadurch können die Teilnehmer die Teilnahme am Protokoll nicht verweigern. es sei denn, sie hatten einen erfolgreichen Konsensangriff. Dieses Sicherheitsniveau ist akzeptabel, daher sollte PVRB genau wie die Blockchain-Hauptkette gegen Absprachen zwischen den Teilnehmern resistent sein. Dies deutet auch darauf hin, dass PVRB Teil des Konsenses sein sollte. Wenn sich das Netzwerk auf die Hauptblockkette geeinigt hat, sollte es sich gleichzeitig auf den einzigen ehrlich resultierenden Zufall einigen. Oder PVRB ist nur ein eigenständiges Protokoll, das von einem intelligenten Vertrag implementiert wird und in Bezug auf Blockchain und Blöcke asynchron arbeitet. Beide Methoden haben ihre Vor- und Nachteile, und die Wahl zwischen ihnen ist äußerst trivial.

Zwei Möglichkeiten zur Implementierung von PVRB

Lassen Sie uns zwei Optionen für die Implementierung von PVRB genauer beschreiben: die eigenständige Version, die mit einem von der Blockchain unabhängigen intelligenten Vertrag arbeitet, und die konsensintegrierte Version, die in das Protokoll integriert ist, nach dem sich das Netzwerk auf eine Kette von Blöcken und eingeschlossenen Transaktionen einigt. In allen Fällen werde ich die beliebten Blockchain-Engines berücksichtigen: Ethereum, EOS und alle ähnlichen, die bei der Platzierung und Verarbeitung intelligenter Verträge ähnlich sind.

Standalone-Vertrag

In dieser Ausführungsform ist PVRB ein intelligenter Vertrag, der Transaktionen mit zufälligen Produzenten (im Folgenden: RP) akzeptiert, verarbeitet, die Ergebnisse kombiniert und als Ergebnis einen Wert erreicht, den jeder Benutzer aus diesem Vertrag erhalten kann. Dieser Wert darf nicht direkt im Vertrag gespeichert werden, sondern wird nur durch Daten dargestellt, aus denen ein und nur ein Wert der resultierenden Zufälligkeit deterministisch erhalten werden kann. In diesem Schema sind RPs Blockchain-Benutzer, und jeder kann am Generierungsprozess teilnehmen.

Die Option für einen eigenständigen Vertrag ist gut:

• Portabilität (Verträge können von Blockchain zu Blockchain gezogen werden)
• Einfachheit bei Implementierung und Test (Verträge sind bequem zu schreiben und zu testen)
• Bequemlichkeit bei der Implementierung von Wirtschaftssystemen (es ist einfach, ein eigenes Token zu erstellen, dessen Logik den Zielen von PVRB dient)
• die Fähigkeit, in vorhandenen Blockchains zu laufen

Es hat auch Nachteile:

• Starke Einschränkungen der Ressourcen bei Berechnungen, Transaktionsvolumen und Speicher (mit anderen Worten: CPU / Mem / Io)
• Betriebsbeschränkungen innerhalb des Vertrags (nicht alle Anweisungen sind verfügbar, es ist schwierig, externe Bibliotheken zu verbinden)
• Die Unfähigkeit, Nachrichten schneller als Transaktionen zu organisieren, ist in der Blockchain enthalten

Diese Option eignet sich für die Implementierung von PVRB, das in einem vorhandenen Netzwerk ausgeführt werden muss, das keine komplexe Kryptografie enthält und keine große Anzahl von Interaktionen erfordert.

Konsens integriert

In dieser Ausführungsform ist PVRB im Blockchain-Knotencode implementiert, ist eingebaut oder arbeitet parallel zum Austausch von Nachrichten zwischen Blockchain-Knoten. Die Protokollergebnisse werden direkt in die erzeugten Blöcke geschrieben, und die Protokollnachrichten werden über das p2p-Netzwerk zwischen den Knoten gesendet. Da das Protokoll dazu führt, dass die Zahlen in Blöcken geschrieben werden, muss das Netzwerk einen Konsens darüber erzielen. Dies bedeutet, dass PVRB-Nachrichten sowie Transaktionen von Knoten validiert und in Blöcken enthalten sein müssen, damit jeder Netzwerkteilnehmer die Einhaltung des PVRB-Protokolls überprüfen kann. Dies führt uns automatisch zu der offensichtlichen Entscheidung: Wenn das Netzwerk einen Konsens über den Block und die darin enthaltenen Transaktionen aushandelt, sollte PVRB Teil des Konsenses sein und kein eigenständiges Protokoll. Andernfalls ist eine Situation möglich, in der der Block unter dem Gesichtspunkt des Konsenses gültig ist, das PVRB-Protokoll jedoch nicht eingehalten wird und der Block aus Sicht des PVRB nicht akzeptiert werden kann. Wenn also die Option „Konsens integriert“ gewählt wird, wird PVRB ein wichtiger Bestandteil des Konsenses.

Wenn Sie die Implementierung von PVRB auf der Ebene des Konsenses im Netzwerk beschreiben, können Sie in keinem Fall die Fragen der Endgültigkeit umgehen. Finalität ist ein Mechanismus, der im deterministischen Konsens verwendet wird, ein Verriegelungsblock (und eine dazu führende Kette), der endgültig ist und niemals weggeworfen wird, selbst wenn eine parallele Gabel erscheint. Zum Beispiel gibt es in Bitcoin keinen solchen Mechanismus. Wenn Sie eine Kette mit größerer Komplexität veröffentlichen, wird diese unabhängig von der Länge der Kette durch eine weniger komplexe ersetzt. In EOS sind die letzten beispielsweise die sogenannten Last Irreversible Blocks, die durchschnittlich alle 432 Blöcke erscheinen (12 * 21 + 12 * 15, Pre-Vote + Pre-Commit). Dieser Prozess wartet im Wesentlichen auf 2/3 der Signaturen der Blockproduzenten (im Folgenden: BP). Wenn Gabeln angezeigt werden, die älter als die letzte LIB sind, werden sie einfach verworfen. Mit diesem Mechanismus können Sie sicherstellen, dass die Transaktion in der Blockchain enthalten ist und niemals abgepumpt wird, unabhängig davon, über welche Ressourcen der Angreifer verfügt. Außerdem sind die letzten Blöcke Blöcke, die von 2/3 BP in Hyperledger, Tendermint und anderen pBFT-basierten Konsensen signiert sind. Ein Protokoll zur Gewährleistung der Endgültigkeit ist auch sinnvoll, um ein Add-On zum Konsens zu erstellen, da es asynchron mit der Erstellung und Veröffentlichung von Blöcken arbeiten kann. Hier ist ein guter Artikel zum Abschluss von Ethereum.

Die Endgültigkeit ist äußerst wichtig für Benutzer, die ohne sie möglicherweise Opfer des Angriffs mit doppelten Ausgaben werden, wenn BP die Blöcke „hält“ und veröffentlicht, nachdem das Netzwerk eine gute Transaktion „gesehen“ hat. Wenn es keine Endgültigkeit gibt, ersetzt die veröffentlichte Abzweigung den Block durch die "gute" Transaktion durch eine andere von der "schlechten" Abzweigung, bei der das gleiche Geld an die Adresse des Angreifers überwiesen wird. Im Fall von PVRB werden die Anforderungen an die Endgültigkeit immer noch verschärft, da der Bau von Gabeln für PVRB bedeutet, dass ein Angreifer mehrere Optionen für ein zufälliges Haus vorbereiten kann, um die für ihn rentabelsten zu veröffentlichen, und die Zeit eines möglichen Angriffs zu begrenzen, ist eine gute Lösung.

Daher ist die beste Option, PVRB und Finalität in einem Protokoll zu kombinieren - dann ist der finalisierte Block = zufällig finalisiert, und genau das mussten Sie bekommen. Jetzt erhalten die Spieler in N Sekunden eine garantierte Zufälligkeit und können sicher sein, dass es unmöglich ist, einen Rollback oder eine Wiederholung durchzuführen.

Die konsensintegrierte Option ist gut:

• die Möglichkeit einer asynchronen Implementierung in Bezug auf die Herstellung von Blöcken - Blöcke werden wie gewohnt erzeugt, aber parallel dazu kann das PVRB-Protokoll funktionieren, das nicht jeden Block zufällig macht
• die Fähigkeit, auch schwere Kryptografie ohne die Einschränkungen für intelligente Verträge zu implementieren
• Die Möglichkeit, Nachrichten schneller zu organisieren, als Transaktionen in der Blockchain enthalten sind. Beispielsweise kann ein Teil des Protokolls zwischen Knoten arbeiten, ohne Nachrichten über das Netzwerk zu verbreiten

Es hat auch Nachteile:

• Schwierigkeiten beim Testen und Entwickeln - Sie müssen Netzwerkfehler, fehlende Knoten und harte Netzwerkgabeln emulieren
• Implementierungsfehler erfordern ein Hard-Fork-Netzwerk

Beide Methoden der PVRB-Implementierung haben das Recht auf Leben, aber die Implementierung intelligenter Verträge in modernen Blockchains ist bei den Rechenressourcen immer noch recht begrenzt, und ein Übergang zu seriöser Kryptografie ist oft einfach unmöglich. Wir werden ernsthafte Kryptographie brauchen, wie später gezeigt wird. Obwohl dieses Problem eindeutig nur vorübergehend ist, ist eine ernsthafte Kryptografie in Verträgen erforderlich, um viele Probleme zu lösen, und es tritt allmählich auf (z. B. Systemverträge für zkSNARKs in Ethereum).

Die Blockchain, die einen transparenten und zuverlässigen Protokollnachrichtenkanal bereitstellt, tut dies aus einem bestimmten Grund. Jedes dezentrale Protokoll muss die Möglichkeit eines Sybil-Angriffs berücksichtigen. Jede Aktion kann von den koordinierten Kräften vieler Konten ausgeführt werden. Daher ist es beim Entwerfen erforderlich, die Fähigkeiten von Angreifern zu berücksichtigen, um eine beliebige Anzahl von Protokollteilnehmern zu erstellen, die in Absprache handeln.

PVRB- und Blockvariablen.

Ich habe nicht gelogen, als ich sagte, dass bisher niemand einen guten PVRB in Blockchains implementiert hat, der von vielen Glücksspielanwendungen verifiziert wurde. Woher also so viele Glücksspielanwendungen in Ethereum und EOS? Es überrascht mich genauso wie Sie. Woher haben Sie in einer vollständig deterministischen Umgebung so viele „beständige“ Zufallszahlen?

Der bevorzugte Weg, um in der Blockchain zufällig zu werden, besteht darin, eine Art „unvorhersehbarer“ Informationen aus dem Block zu entnehmen und darauf basierend zufällig zu arbeiten - einfach einen oder mehrere Werte zwischenzuspeichern. Ein guter Artikel über die Probleme solcher Systeme hier . Sie können einige der „unvorhersehbaren“ Werte im Block verwenden, z. B. den Hash des Blocks, die Anzahl der Transaktionen, die Komplexität des Netzwerks und andere im Voraus unbekannte Werte. Dann zwischenspeichern Sie sie, eine oder mehrere, und theoretisch sollten Sie einen echten Zufall erhalten. Sie können wihitepaper sogar hinzufügen, dass Ihr Schema "postquantensicher" ist (da es quantensichere Hash-Funktionen gibt :)).

Aber selbst postquantensichere Hashes reichen leider nicht aus. Das Geheimnis liegt in den Anforderungen an PVRB, ich erinnere mich an sie aus einem früheren Artikel:

1. Das Ergebnis sollte eine nachweislich gleichmäßige Verteilung aufweisen, d. H. Basierend auf einer nachweislich starken Kryptographie.
2. Es ist nicht möglich, eines der Bits des Ergebnisses zu steuern. Infolgedessen kann das Ergebnis nicht im Voraus vorhergesagt werden.
3. Sie können das Generierungsprotokoll nicht sabotieren, indem Sie nicht am Protokoll teilnehmen oder das Netzwerk mit Angriffsnachrichten überlasten
4. Alle oben genannten Punkte sollten gegen Absprachen der zulässigen Anzahl unehrlicher Teilnehmer am Protokoll (z. B. 1/3 der Teilnehmer) resistent sein.

In diesem Fall ist nur die Anforderung 1 erfüllt und 2. ist nicht erfüllt. Wenn unvorhersehbare Werte aus dem Block entfernt werden, erhalten wir eine gleichmäßige Verteilung und eine gute Zufälligkeit. Aber BP hat zumindest die Möglichkeit, "einen Block zu veröffentlichen oder nicht". Somit kann BP mindestens aus ZWEI Zufallsoptionen auswählen: "unsere" und eine, die sich herausstellt, wenn jemand anderes den Block macht. BP kann im Voraus „ausspionieren“, was passiert, wenn ein Block veröffentlicht wird, und entscheidet sich einfach dafür oder nicht. Wenn er beispielsweise beim Roulette „ungerade-gerade“ oder „rot / schwarz“ spielt, kann er einen Block nur veröffentlichen, wenn er einen Gewinn sieht. Es macht auch eine unoperative Strategie, um zum Beispiel einen Hash eines Blocks aus der Zukunft zu verwenden. In diesem Fall heißt es: „Es wird ein Zufall verwendet, der durch Hashing der aktuellen Daten und des Hash des zukünftigen Blocks mit einer Höhe von beispielsweise N + 42 erhalten wird, wobei N die aktuelle Blockhöhe ist. Dies stärkt das Schema ein wenig, ermöglicht es BP jedoch, wenn auch in Zukunft, den Block auszuwählen, zu halten oder zu veröffentlichen.

Soft BP ist in diesem Fall kompliziert, aber nicht viel. Es ist nur so, dass bei der Validierung und Aufnahme einer Transaktion in den Block schnell überprüft wird, ob ein Gewinn erzielt wird, und möglicherweise die Auswahl eines Transaktionsparameters, um eine hohe Gewinnwahrscheinlichkeit zu erzielen. Gleichzeitig ist es fast unmöglich, einen intelligenten BP für solche Manipulationen zu finden, jedes Mal, wenn Sie neue Adressen verwenden und ein wenig gewinnen können, ohne Verdacht zu erregen.

Daher sind die Methoden, die Informationen aus dem Block verwenden, nicht für die Rolle der universellen Implementierung von PVRB geeignet. In einer eingeschränkten Version mit Einschränkungen bei der Größe der Wetten, Einschränkungen bei der Anzahl der Spieler und / oder der KYC-Registrierung (um zu verhindern, dass ein Spieler mehrere Adressen verwendet) können diese Schemata für kleine Spiele verwendet werden, mehr jedoch nicht.

PVRB und Commit-Enthüllung.

Okay, dank Hashing und zumindest der relativen Unvorhersehbarkeit des Block-Hash und anderer Variablen. Wenn Sie das Problem der Front-Running-Bergleute lösen, sollten Sie sich etwas Passenderes zulegen. Fügen wir diesem Schema Benutzer hinzu - obwohl sie auch die Zufälligkeit beeinflussen: Jede Person des technischen Supports wird Ihnen sagen, dass Benutzeraktionen in IT-Systemen am zufälligsten sind :)

Das naive Schema, bei dem Benutzer einfach Zufallszahlen senden und das Ergebnis beispielsweise als Hash ihrer Summe berechnet wird, ist nicht geeignet. In diesem Fall kann der letzte Spieler seine eigene zufällige Kontrolle über das Ergebnis wählen. Daher wird das sehr weit verbreitete Commit-Enthüllungsmuster verwendet. Die Teilnehmer senden zuerst Hashes von ihren Zufallszahlen (Commits) und öffnen dann die Zufallszahlen selbst. Die "Enthüllungs" -Phase beginnt erst, nachdem das erforderliche Commit gesammelt wurde, sodass die Teilnehmer genau den Zufall senden können, von dem sie zuvor einen Hash gesendet haben. Jetzt blenden wir das alles mit den Parametern des Blocks und es ist besser als das aus der Zukunft (Sie können die Zufälligkeit nur in einem der zukünftigen Blöcke herausfinden) und voila - der Zufall ist fertig! Jetzt beeinflusst jeder Spieler die resultierende Zufälligkeit und kann den böswilligen BP „besiegen“, indem er ihn mit seinem eigenen, zuvor unbekannten Zufall blockiert. Sie können auch Schutz vor Sabotage des Protokolls hinzufügen, indem Sie es nicht in der Enthüllungsphase öffnen - Sie müssen lediglich einen bestimmten Betrag auf die Transaktion anwenden - Versicherungskaution, die nur während des Offenlegungsverfahrens zurückerstattet wird. In diesem Fall ist es nachteilig, Commit zu machen und nicht zu enthüllen.

Es war ein guter Versuch, und solche Schemata sind auch in Spiel-DApps enthalten, aber leider reicht dies wiederum nicht aus. Jetzt kann nicht nur der Bergmann, sondern jeder Teilnehmer am Protokoll das Ergebnis beeinflussen. Es ist weiterhin möglich, den Wert selbst mit einem geringeren Grad an Variabilität und für Geld zu kontrollieren. Wenn jedoch wie im Fall des Bergmanns die Ergebnisse der Ziehung wertvoller sind als die Teilnahmegebühr am PVRB-Protokoll, kann der Zufallsproduzent (RP) entscheiden, ob er sie preisgibt und kann immer noch aus mindestens zwei zufälligen Optionen wählen.
Aber es gab die Möglichkeit, diejenigen zu bestrafen, die sich verpflichten und nicht preisgeben, und dieses Schema ist immer noch nützlich. Die Einfachheit ist ein großer Vorteil - ernstere Protokolle erfordern viel leistungsfähigere Computer.

PVRB und deterministische Signaturen.

Es gibt eine andere Möglichkeit, ein RP dazu zu bringen, eine Pseudozufallszahl bereitzustellen, die nicht beeinflusst werden kann, wenn es mit einem „Prototyp“ versehen ist - dies ist eine deterministische Signatur. Eine solche Signatur ist beispielsweise RSA und kein ECS. Wenn RP ein Schlüsselpaar hat: RSA und ECC, und er einen Wert mit seinem privaten Schlüssel signiert, erhält er im Fall von RSA EINE UND NUR EINE Signatur, und im Fall von ECS kann er eine beliebige Anzahl verschiedener gültiger Signaturen generieren. Dies liegt an der Tatsache, dass beim Erstellen einer ECS-Signatur eine Zufallszahl verwendet wird, die von den Unterzeichnern ausgewählt wird und nach Wunsch ausgewählt werden kann, sodass der Unterzeichner die Möglichkeit hat, eine von mehreren Signaturen auszuwählen. Im Fall von RSA: "ein Eingabewert" + "ein Schlüsselpaar" = "eine Signatur". Es ist unmöglich vorherzusagen, wie die Signatur des anderen RP aussehen wird, daher kann PVRB mit deterministischen Signaturen organisiert werden, indem RSA-Signaturen mehrerer Teilnehmer kombiniert werden, die denselben Wert signiert haben. Zum Beispiel - der vorherige Zufall. In diesem Schema werden viele Ressourcen gespart, weil Signaturen sind sowohl eine Bestätigung der Richtigkeit des Protokollverhaltens als auch eine Quelle der Zufälligkeit.

Selbst bei deterministischen Signaturen ist das Schema jedoch immer noch anfällig für das Problem des „letzten Akteurs“. Der letzte Teilnehmer kann weiterhin entscheiden, ob er seine Unterschrift veröffentlicht oder nicht, und so das Ergebnis kontrollieren. Sie können das Schema verfeinern, Block-Hashes hinzufügen, Runden erstellen, sodass das Ergebnis nicht im Voraus vorhergesagt werden kann. Alle diese Methoden lassen jedoch auch unter Berücksichtigung vieler Verbesserungen das Problem des Einflusses eines Teilnehmers auf das kollektive Ergebnis in einer nicht vertrauenswürdigen Umgebung ungelöst und können nur funktionieren unter wirtschaftlichen und zeitlichen Bedingungen. Darüber hinaus ist die Größe von RSA-Schlüsseln (1024 und 2048 Bit) ziemlich groß, und die Größe für Blockchain-Transaktionen ist ein äußerst wichtiger Parameter. Anscheinend wird es auf einfache Weise nicht funktionieren, wir gehen weiter.

PVRB- und geheime Austauschprogramme

In der Kryptographie gibt es Schemata, mit denen sich das Netzwerk auf einen und nur einen Wert von PVRB einigen kann, während solche Schemata gegen böswillige Handlungen eines Teils der Teilnehmer resistent sind. Ein nützliches Protokoll zum Kennenlernen ist Shamirs geheimes Freigabeschema. Es dient dazu, ein Geheimnis (zum Beispiel einen geheimen Schlüssel) in mehrere Teile aufzuteilen und diese Teile an N Teilnehmer zu verteilen. Das Geheimnis ist so verteilt, dass M Teile von N für seine Wiederherstellung ausreichen, während es beliebige M Teile sein können. Wenn sich die Teilnehmer an den Fingern befinden und ein Diagramm einer unbekannten Funktion haben, tauschen sie Punkte auf dem Diagramm aus, und nachdem sie M Punkte erhalten haben, kann die gesamte Funktion wiederhergestellt werden.
Eine gute Erklärung finden Sie im Wiki. Auf der Demoseite ist es hilfreich, praktisch damit zu spielen, um das Protokoll in Ihrem Kopf zu verlieren.

Wenn das FSSS-System (Fiat-Shamir Secret Sharing) in seiner reinen Form anwendbar wäre, wäre es ein nicht tötbarer PVRB. In der einfachsten Version sieht das Protokoll möglicherweise folgendermaßen aus:

• Jeder Teilnehmer generiert seinen eigenen Zufall und verteilt daraus Anteile an die anderen Teilnehmer
• M shares, , ,
• random- PVRB

, , threshold- . , RP , , “last actor”.

, PVRB secret sharing - , , . , , , . - EOS — share : . , proof- , . , verify , block-producer , , verify . , (0.5 ).

— - . proof-, — off-chain , — PVRB.

PVRB threshold signatures

secret sharing, , “threshold”. M N, N, “threshold” . “last actor”, , , . , .

threshold- PVRB — threshold-. threshold-, longread Dash.

BLS (BLS Boneh-Lynn-Shacham, ), — , , BLS , , . . , BLS , , M N , , publicly verifiable, , M- .

threshold BLS signatures BLS - ( ), threshold- . BLS , threshold- “last-actor”, , , , .

, PVRB , BLS threshold signatures, . , DFinity ( , , verifiable secret sharing), Keep.network ( random beacon yellowpaper , -, ).

PVRB

, , PVRB , . , , . PVRB , : CPU, memory, storage, I/O. PVRB — , , . , RP, , proof- , .

, PVRB:

• . PVRB unbiasable, . ,
• “last actor” . PVRB , , RP .
• . PVRB , , RP , ,
• . RP “ , ”. p2p , ,
• . PVRB on-chain , . -,
• liveness . PVRB , RP
• trusted setup . PVRB setup , . . - — ,
• . , , , ..

threshold BLS — , , , threshold. , , , , , , , realtime, , , threshold . , threshold-, , (slashing) , . , BLS , , EOS Ethereum — . — WebAssembly EVM, . (), . , 1024 2048 bit RSA, 4-8 , Bitcoin Ethereum.

— , . , Go geth, Rust Parity, C++ EOS. JavaScript , JavaScript , WebAssembly, -.

Fazit

, , , , , . , , setup- , whitepaper- , - “ , ”.

, PVRB Haya , threshold BLS signatures, PVRB , - . , : secret sharing random_seed, threshold BLS , . , , , , , , — , , . — , , governance .

PVRB, , , , , , , , , , - . , , .

, , , , :)