Multi-Signed Wallet Hierarchy (Vertrauenssystem)

Dieser Text beschreibt die Abstraktion eines Vertrauenssystems, mit dem Sie Treuhanddienste in jeden Bereich der Wirtschaftsbeziehungen integrieren können.
Die Einzahlung von Geldern ist ein wesentlicher Bestandteil jeder Transaktion. Wenn die Gegenparteien keine verlässlichen Informationen über einander kennen, steigt das Betrugsrisiko. Mit diesem Ansatz können Sie in einem dezentralen Netzwerk ein Streitbeilegungsmodell, ein Modell für die Durchführung automatischer Transaktionen, sichere Transaktionen usw. programmieren. Darüber hinaus ist ein solches Modell eines Vertrauenssystems offen. Alle Transaktionen, die unter Beteiligung der Multi-Subscription-Wallet-Hierarchie durchgeführt werden, ermöglichen es uns, das Rating der Gegenpartei zu überprüfen und uns vor betrügerischen Schemata neuer Teilnehmer an Wirtschaftsbeziehungen zu schützen.

Inhalt

1 Einleitung
2 Beschreibung einer Brieftasche mit mehreren Signaturen
3 Möglichkeiten zum Erstellen einer Brieftaschenhierarchie
4 Mehrtägige Benutzeroberfläche für die Brieftaschenhierarchie
5 Interaktionsströme
5.1 Standard-Interaktionsfluss
5.2 Sicherer Interaktionsfluss
5.3 Umstrittener Interaktionsfluss
6 Protokoll ESCB9
7 Integration eines Vertrauenssystems und intelligenter Verträge zur Implementierung des ESCB9-Protokolls
8 Beispiele für Verträge, die ESCB9 implementieren
8.1 Smart Contract für den privaten Vermietungsmarkt nach dem Vorbild von AirBnb
8.2 Ein intelligenter Vertrag für den Austausch einer Kryptowährung gegen Fiat-Geld und zurück in einem dezentralen Modus
9 Schiedsgerichtsknoten
10 Wörterbuch

1. Einleitung

Das Hauptproblem für Treuhanddienste ist die Schaffung vertrauensvoller Beziehungen zwischen allen Teilnehmern. Darüber hinaus sollten die Teilnehmer selbst nicht unbedingt jedem Thema der Beziehungen bekannt sein. Um alle Fälle zusammenzufassen, werden wir berücksichtigen, dass sie alle anonym sind. Für ein solches vertrauensvolles Beziehungssystem ist es wichtig, die Beziehungen neuer Teilnehmer zu alten zu regeln. Alte Teilnehmer haben bereits eine bestimmte Bewertung im Beziehungssystem und sorgen so für mehr Vertrauen. Da niemand im Vertrauenssystem jemanden kennt, führt dies zu Problemen bei der Überprüfung der vorherigen Bewertung. Dieses Dokument beschreibt das Vertrauenssystem, das auf Crypto-Wallets mit mehreren Abonnements basiert. Ein solches System kann in einen intelligenten Vertrag programmiert werden. Angesichts der breiten Verbreitung der Ethereum-Plattform werden wir diese Plattform als Plattform für die Beschreibung aller intelligenten Verträge in diesem Dokument auswählen.

2. Beschreibung einer Brieftasche mit mehreren Signaturen

Eine Abstraktion, mit der Sie Transaktionen nur dann bestätigen oder abbrechen können, wenn zwischen den autorisierten Teilnehmern ein Konsens erzielt wurde, um eine solche Entscheidung zu treffen, wird als Brieftasche mit mehreren Signaturen bezeichnet. Eine Transaktion ist in diesem Zusammenhang eine atomare Operation, die so programmiert ist, dass sie eine Methode in einem anderen oder demselben intelligenten Vertrag ausführt.

Die Schnittstelle für den Smart-Vertrag einer solchen Abstraktion kann dargestellt werden als:

1. Der Konstrukteur akzeptiert die Adressen der Gründungsmitglieder und die Anzahl der erforderlichen Mindestbestätigungen für Transaktionen
   

   constructor(address[]:members, uint256:requiredConfirmationCount) 

   
   
2. Autorisierte Teilnehmerschnittstelle
   
   1. eine Liste der Teilnehmer erhalten
      

       static getMembers() -> address[]:address 

      
      
   2. Mitgliedsadresse anzeigen
      

       static getMember(uint256:indexNumber) -> address:address 

      
      
   3. Überprüfung der Adresse für die Mitgliedschaft
      

       static isMember(address:address) -> bool:value 

      
      
   4. Erhalten der maximalen Teilnehmerzahl für die Brieftasche
      

       static getMaxMemberCount() -> uint256:value 

      
      
   5. Mindestkonsensbestätigung
      

       static getRequiredConfirmationCount() -> uint256:value 

      
      
   6. Ereignis des Hinzufügens eines neuen Mitglieds
      

       event MemberAddition() -> address:member 

      
      
   7. Ereignis zum Löschen von Mitgliedern
      

       event MemberRemoval() -> address:member 

      
      
   8. Das Ereignis ändern erfordert die Anzahl der auszuführenden Bestätigungen
      

       event RequiredConfirmationCountChange() -> uint256:count 

      
      
   9. Mitglied hinzufügen
      

       execute addMember(address:member) -> void:value 

      
      
   10. Löschung von Mitgliedern
       

        execute removeMember(address:member) -> void:value 

       
       
   11. Mitgliederersatz
       

        execute replaceMember(address:currentMember, address:newMember) -> void:value 

   12. Änderung der Anzahl der obligatorischen Bestätigungen für die Ausführung
       

        execute changeRequiredConfirmationCount(uint256:count) -> void:value 

       
       
   
   
3. Transaktionsschnittstelle
   
   1. Überprüfung der Transaktionsbestätigung an der Adresse des Teilnehmers
      

       static getConfirmationByAddress(uint256:indexNumber, address:addressMember) -> bool:value 

      
      
   2. Informationen aus einer Transaktion abrufen
      

       static getTransactionInfo(uint256:indexNumber) -> [address:destination, uint256:value, bytes:data, bool:executed] 

   3. Abrufen der Gesamtzahl der Transaktionen in dieser Brieftasche
      

       static getTransactionCount() -> uint256:value 

   4. Transaktionsbestätigungsstatus erhalten
      

       static isConfirmed(uint256:transactionId) -> bool:value 

   5. Erhalt der Anzahl der Bestätigungen
      

       static getConfirmationCount(uint256:transactionId) -> uint256:count 

   6. Abrufen der Anzahl der Transaktionen nach Typ
      

       static getTransactionCount(bool:pending, bool:executed) -> uint256:count 

   7. Abrufen der Liste der Teilnehmer, die die Transaktion bestätigt haben
      

       static getConfirmations(uint256:transactionId) -> address[]:confirmations 

   8. Abrufen einer Liste der Transaktions-ID nach Typ in einem bestimmten Zeitraum
      

       static getTransactionIds(uint256:from, uint256:to, bool:pending, bool:executed) -> uint256[]:transactionIds 

   9. Ereignis zur Bestätigung der Partytransaktion
      

       event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

   10. Rücknahmeereignis zur Bestätigung der Teilnehmer vor der Transaktion
       

        event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

   11. Warteschlangentransaktion Ereignis hinzufügen
       

        event Submission() -> [uint256:transactionId] 

   12. Transaktionsausführungsereignis
       

        event Execution() -> [uint256:transactionId] 

   13. Transaktionsfehlerereignis
       

        event ExecutionFailure -> [uint256:transactionId] 

   14. Brieftaschenauffüllungsereignis
       

        event Deposit -> [address:sender, uint256:amount] 

   15. Mitglied fügt Transaktion hinzu
       

        execute submitTransaction(address:destination, uint256:value, bytes:data) -> uint256:transactionId 

   16. Transaktionsbestätigung durch den Teilnehmer
       

        execute confirmTransaction(uint256:transactionId) -> void:value 

   17. Widerruf der Bestätigung durch den Teilnehmer
       

        execute revokeConfirmation(uint256:transactionId) -> void:value 

   18. manuelle Transaktion
       

        execute executeTransaction(uint256:transactionId) -> void:value 

   
   

3 Möglichkeiten zum Erstellen einer Brieftaschenhierarchie

Es gibt zwei Möglichkeiten, ein Vertrauenssystem aufzubauen. Vertikal und horizontal. Die horizontale Bauweise impliziert die Erstellung einer Liste von untergeordneten Geldbörsen durch einen Hauptelternteil. Die vertikale Bauweise impliziert eine Kette, die aus untergeordneten Geldbörsen in Bezug auf die Eltern besteht. In diesem Fall kann die übergeordnete Brieftasche ein Kind einer anderen übergeordneten Brieftasche sein.
Wie wir sehen, kann der horizontale Konstruktionspfad eine Unterart des vertikalen Konstruktionspfads sein. Daher lassen wir diesen Ansatz weiter unbeaufsichtigt.

4 Mehrtägige Benutzeroberfläche für die Brieftaschenhierarchie

Um ein Vertrauenssystem aufzubauen, muss die oben beschriebene einfache Oberfläche der Multi-Subscription-Brieftasche erweitert werden, um Mechanismen zur Regulierung der Hierarchie und zur automatischen Ausführung von Bestätigungen sowie die Möglichkeit einer verzögerten Ausführung hinzuzufügen.

1. Der Konstruktor akzeptiert die Adresse der übergeordneten Brieftasche, die Adressen der Gründungsmitglieder, die Anzahl der erforderlichen Mindestbestätigungen für Transaktionen und die Standardzeit für automatische Bestätigungen in Sekunden
   

    constructor(address:parent, address[]:members, uint256:requiredConfirmationCount, uint256:standardTimeAutoConfirmation) 

   
   
2. Mitgliederschnittstelle
   
   1. eine Liste der Teilnehmer erhalten
      

       static getMembers() -> address[]:address 

      
      
   2. Funktion zum Anzeigen der Adresse des Teilnehmers
      

       static getMember(uint256:indexNumber) -> address:address 

      
      
   3. Überprüfung der Adresse für die Mitgliedschaft
      

       static isMember(address:address) -> bool:value 

      
      
   4. Erhalten der maximalen Anzahl von Wallet-Teilnehmern
      

       static getMaxMemberCount() -> uint256:value 

      
      
   5. Mindestkonsensbestätigung
      

       static getRequiredConfirmationCount() -> uint256:value 

      
      
   6. Ereignis des Hinzufügens eines neuen Mitglieds
      

       event memberAddition() -> address:member 

      
      
   7. Ereignis zum Löschen von Mitgliedern
      

       event memberRemoval() -> address:member 

      
      
   8. Das Ereignis ändern erfordert die Anzahl der auszuführenden Bestätigungen
      

       event requiredConfirmationCountChange() -> uint256:count 

      
      
   9. Mitglied hinzufügen
      

       execute addMember(address:member) -> void:value 

      
      
   10. Löschung von Mitgliedern
       

        execute removeMember(address:member) -> void:value 

       
       
   11. Mitgliederersatz
       

        execute replaceMember(address:currentMember, address:newMember) -> void:value 

       
       
   12. Änderung der Anzahl der obligatorischen Bestätigungen für die Ausführung
       

        execute changeRequiredConfirmationCount(uint256:count) -> void:value 

       
       
   
   
3. Hierarchie-Schnittstelle
   
   1. eine Liste der Kinderbrieftaschen bekommen
      

       static getChildren() -> address[]:wallets 

      
      
   2. Überprüfen Sie, ob die Brieftaschenadresse ein Kind der aktuellen Adresse ist
      

       static isChild() -> bool:value 

      
      
   3. Die Überprüfung, ob die Brieftaschenadresse der aktuellen Adresse entspricht, erfolgt über isChild, indem sie gegenübergestellt wird.
      
   4. Affiliate Wallet Attachment Event
      

       event childAttachment() -> [address:address,uint256:timeStamp] 

      
      
   5. Ereignis zum Entfernen der Brieftasche für Kinder
      

       event childRemoval() -> [address:address,uint256:timeStamp] 

      
      
   6. Anbringen einer Kinderbrieftasche
      

       execute attachChild(addres:child) -> void:value 

      
      
   7. Kindergeldbörse löschen
      

       execute removeChild(address:address) -> void:value 

      
      
   8. Ändern Sie eine Kinderbrieftasche in eine andere
      

       execute replaceChild(address:newAddress) -> void:value 

      
      
   
   
4. Transaktionsschnittstelle
   
   1. Überprüfen Sie den Transaktionsstatus
      

       static getTransactionStatus(uint256:transactionId) -> enum:{submitted,completed,frozen,disputed,reverted} 

      
      
   2. Überprüfen des Transaktionsstatus auf Konformität
      

       static isTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> bool:value 

      
      
   3. Überprüfung der Transaktionsbestätigung an der Adresse des Teilnehmers
      

       static getConfirmationByAddress(uint256:transactionId, address:addressMember) -> bool:value 

      
      
   4. Informationen aus einer Transaktion abrufen
      

       static getTransactionInfo(uint256:transactionId) -> [address:destination, uint256:value, bytes:data, bool:executed] 

      
      
   5. Abrufen der Gesamtzahl der Transaktionen in der Brieftasche
      

       static getTransactionCount() -> uint256:value 

      
      
   6. Transaktionsbestätigungsstatus erhalten
      

       static isConfirmed(uint256:transactionId) -> bool:value 

      
      
   7. Erhalt der Anzahl der Bestätigungen
      

       static getConfirmationCount(uint256:transactionId) -> uint256:count 

      
      
   8. Abrufen der Anzahl der Transaktionen nach Typ
      

       static getTransactionCount(bool:pending, bool:executed) -> uint256:count 

      
      
   9. Abrufen der Liste der Teilnehmer, die die Transaktion bestätigt haben
      

       static getConfirmations(uint256:transactionId) -> address[]:confirmations 

      
      
   10. Zeit für die automatische Bestätigung bekommen
       

        static getTimeAutoConfirmation(uint256:transactionId) -> uint256:timestamp 

       
       
   11. Abrufen einer Liste der Transaktions-ID nach Typ in einem bestimmten Zeitraum
       

        static getTransactionIds(uint256:from, uint256:to, bool:pending, bool:executed) -> uint256[]:transactionIds 

       
       
   12. Ereignis zur Bestätigung der Partytransaktion
       

        event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

       
       
   13. automatisches Transaktionsbestätigungsereignis
       

        event AutoConfirmation() -> [uint256:transactionId, uint256:timeStamp] 

       
       
   14. Rücknahmeereignis zur Bestätigung der Teilnehmer vor der Transaktion
       

        event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp] 

       
       
   15. Warteschlangentransaktion Ereignis hinzufügen
       

        event Submission() -> [uint256:transactionId] 

       
       
   16. Transaktionsausführungsereignis
       

        event Execution() -> [uint256:transactionId] 

       
       
   17. Transaktionsfehlerereignis
       

        event ExecutionFailure -> [uint256:transactionId] 

       
       
   18. Änderung des Transaktionsstatus in eingefrorenes Ereignis
       

        event TransactionFrozen -> [uint256:transactionId] 

       
       
   19. Transaktionsstatusänderung zu kontroversem Ereignis
       

        event TransactionDisputed -> [uint256:transactionId] 

       
       
   20. Änderung des Transaktionsstatus zum zurückgegebenen Ereignis
       

        event TransactionReverted -> [uint256:transactionId] 

       
       
   21. Brieftaschenauffüllungsereignis
       

        event Deposit -> [address:sender, uint256:amount] 

       
       
   22. Fügen Sie die auszuführende Transaktion hinzu
       

        execute submitTransaction(address:destination, uint256:value, uint256:TimeAutoConfirmation, bytes:data) -> uint256:transactionId 

       
       
   23. Transaktionsbestätigung
       

        execute confirmTransaction(uint256:transactionId) -> void:value 

       
       
   24. Widerrufsbestätigung
       

        execute revokeConfirmation(uint256:transactionId) -> void:value 

       
       
   25. Ändern Sie den Transaktionsstatus in eingefroren
       

        execute setTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> void:value 

       
       
   26. manuelle Transaktion
       

        execute executeTransaction(uint256:transactionId) -> void:value 

       
       
   
   
5. Rating Management
   
   1. eine Bewertung erhalten bei
      

       static getRatingByAddress(address:agent) -> [uint256:negativeRating, uint256:positiveRating, uint256:countRatingRecords] 

      
      
   2. Abrufen des Bewertungsverlaufs nach Adresse und Seriennummer
      

       static getRatingRecordForAddress(address:agent, uint256:indexNumber) -> void:value 

      
      
   3. Ereignis des Hinzufügens eines Datensatzes zur Bewertung bei
      

       event RatingRecordAdded -> [address:author, address:agent, bytes32:smartContractAddress, bool:positiveOrNegative, uin256:ratingNumber, bytes:comment, uint256:indexNumber] 

      
      
   4. Datensatz zur Bewertung der Adresse hinzufügen
      

       execute addRatingRecord(address:agent, bytes32:smartContractAddress, bool:positiveOrNegative, uin256:ratingNumber, bytes:comment) -> void:value 

      
      
   
   
6. Integration mit dem ESCB9-Protokoll
   
   1. Überprüfen an der Adresse, ob es sich bei dem an diese Brieftasche angehängten Smart-Vertrag um einen Smart-Vertrag mit ESCB9-Implementierung handelt
      

        static isAttachedESCB9SmartContract(address:smartContract) -> bool:result 

      
      
   2. Überprüfen des Einzahlungsstatus für einen intelligenten Vertrag mit ESCB9, der an diese Brieftasche angehängt ist
      

        static getDepositStatusForESCB9SmartContract(address:smartContract) -> enum:{awaiting,founded,returned} 

      
      
   3. Ereignis des Anhängens eines intelligenten Vertrags mit der Implementierung der ESCB9-Brieftasche
      

       event AttachingESCB9SmartContract -> [address:smartContract] 

      
      
   4. Einzahlungsereignis für einen intelligenten Vertrag mit Implementierung der ESCB9-Brieftasche
      

       event ConfirmationForDepositESCB9SmartContract -> [address:smartContract, uint256:sum, bytes:notice] 

      
      
   5. Anhängen eines intelligenten Vertrags mit der Implementierung von ESCB9 an die Brieftasche
      

       execute attachESCB9SmartContract(address:smartContract) -> void:value 

      
      
   6. Einzahlungsbestätigung für einen intelligenten Vertrag mit ESCB9-Implementierung. Wenn sich die Einzahlung im externen System befindet, wird der Hinweis mit einem Etikett versehen. Wenn sich die Einzahlung in der ETH befindet, wird der Einzahlungsbetrag bei Ausführung der Methode gesendet.
      

       execute fundDepositForESCB9SmartContract(address:smartContract, uint256:sum, bytes:notice) -> void:value 

      
      
   
   

5 Interaktionsströme

Jeder intelligente Vertrag kann in die Hierarchie der Brieftaschen mit mehreren Signaturen integriert werden. Eine solche Integration wird Wechselwirkungsströme haben. Im Allgemeinen unterscheiden wir verschiedene Arten von Flüssen:

• Standard . In diesem Formular erfolgt die Transaktion automatisch. Ohne die Teilnahme autorisierter Mitglieder der Brieftaschenhierarchie.
• Geschützt . In diesem Formular kann die Transaktionszeit vom Standard für die automatische Bestätigung der Zeit auf die erforderliche Zeit erhöht werden. In diesem Fall ist die Teilnahme autorisierter Mitglieder der Brieftaschenhierarchie erforderlich.
• Umstritten . In diesem Formular kann der Transaktionsteilnehmer die Transaktion einfrieren. In diesem Fall ist die Teilnahme autorisierter Mitglieder der Brieftaschenhierarchie erforderlich, um einen Konsens herzustellen.

Jede Brieftasche im Vertrauenssystem hat eine Reihe von bevollmächtigten Teilnehmern, die ein Urteil fällen. Aus einfachen Gründen werden wir alle autorisierten Teilnehmer an der Brieftasche in einem Konzept zusammenfassen - dem Schiedsrichter .

5.1 Standard-Interaktionsfluss

Zur Vereinfachung der Darstellung bringen wir das Konzept von Waren und Dienstleistungen in das Konzept des Übertragungsobjekts (Objekt) und das Konzept von Fiat Money, Kryptowährung, in das Konzept der Übertragungsmittel (Mittel).
Die Gegenpartei, der Eigentümer des Objekts, schließt zum Zweck des Austauschs einen Vertrag mit der Gegenpartei, dem Eigentümer der Fonds. In diesem Fall erstellt der Eigentümer des Objekts einen intelligenten Treuhandvertrag, indem er eine standardisierte Transaktion an eine der autorisierten Brieftaschen in der Hierarchie der Brieftaschen mit mehreren Signaturen sendet. In diesem Fall wird die Transaktion von einem Dritten als Vertrauenssystem registriert. Für jede Transaktion wird die Standardzeit für ihre Ausführung bestimmt. Die Gegenpartei, der Eigentümer des Fonds, leistet eine Einzahlung bei der Transaktion, indem sie das Geld an das Treuhandsystem überweist. Danach überträgt der Eigentümer des Objekts das Objekt an den Eigentümer des Geldes. Der Eigentümer des Fonds überprüft die Qualität des Objekts. Wenn er vor Ablauf der Transaktionszeit die Qualität nicht bestätigt hat, wird das Geld innerhalb der Transaktion an den Eigentümer des Objekts überwiesen. Beide Gegenparteien geben sich gegenseitig Komfortbewertungen. Somit kann der Eigentümer des Fonds den Interaktionsfluss ändern, bis die Transaktion abgeschlossen ist. Nach der Überweisung von Geldern an den Eigentümer des Objekts kann der Eigentümer des Geldes einen höheren Geldbeutel auf Hierarchieebene beantragen, um Streitigkeiten innerhalb der in der Verordnung festgelegten Zeit beizulegen. Nach dieser Zeit werden die Ratings für die Transaktion auf beide Parteien angewendet und die Transaktion wird unwiderruflich.

5.2 Sicherer Interaktionsfluss

Wenn aus bestimmten Gründen, die außerhalb der Kontrolle der Gegenparteien liegen, die Frist für die Transaktion verlängert werden muss, kann die Multi-Signature-Hierarchie-Brieftasche (Arbiter) nach Vereinbarung der Parteien die für die Transaktion vorgesehene Zeit ändern. Nach dem Ändern der Zeit kehrt der der Transaktion zugewiesene Interaktionsfluss auf die Logikstufe des Standardflusses zurück.

5.3 Umstrittener Interaktionsfluss

Wenn die Qualität des Objekts während der Transaktion nicht der Gegenpartei entspricht, dem Eigentümer des Geldes, das er zum Vertrauenssystem der Hierarchie der Brieftaschen mit mehreren Signaturen beiträgt, kann die Transaktion eingefroren werden. In diesem Fall wird die Anzahlung erst dann an die Gegenpartei, den Eigentümer des Objekts, übertragen, wenn ein Urteil über die Transaktion gefällt wurde. Der Inhaber der Fonds muss dem Schiedsrichter der Transaktion wesentliche Nachweise vorlegen. Danach fällt der Schiedsrichter ein Urteil zugunsten einer der Gegenparteien. Wenn eine Partei der Transaktion mit dem Urteil nicht zufrieden ist, wird eine höhere Brieftasche in der Reihenfolge in der Hierarchie der Brieftaschen mit mehreren Signaturen verwendet. Nachdem alle Hierarchieinstanzen bestanden wurden, kann jede Partei eine öffentliche Abstimmung beantragen. Diese außergewöhnliche Maßnahme kann nur durch einen absoluten Geldbeutel zugewiesen werden.

6 Protokoll ESCB9

Ein Beispiel für das ESCB9-Protokoll in Solidity als abstrakter Smart-Vertrag (das Protokoll befindet sich in der Entwicklung und kann sich ändern).

 contract ESCB9 { /** * Modificator for arbitrage */ modifier onlyArbitrage() { require(msg.sender == arbitrage()); _; } /** * Modificator for checking deposit status */ modifier isDeposited { uint i; bytes memory _funcName = bytes4(keccak256("getDepositStatusForESCB9SmartContract(address)")); bytes memory _concat = new bytes(_funcName.length + 32); for(i=0; i < address(this).length; i++) { _concat[i] = address(this)[i]; } require(arbitrage().call.value(0)(_concat) == 1); // “founded” for enum _; } event confirmed(uint256 unixtimestamp, bytes32 notice); event frozen(uint256 unixtimestamp, bytes32 notice); event disputed(uint256 unixtimestamp, bytes32 notice); event canceled(uint256 unixtimestamp, bytes32 notice); /** * @notice Function to approve escrow deal and confirm success * @return Success of operation **/ function confirm(notice) public onlyArbitrage returns(bool); /** * @notice Function to freeze escrow deal * @return Success of operation **/ function freeze(notice) public onlyArbitrage returns(bool); /** * @notice Function to dispute escrow deal * @return Success of operation **/ function dispute(notice) public onlyArbitrage returns(bool); /** * @notice Function to cancel escrow deal and confirm fail * @return Success of operation **/ function cancel(notice) public onlyArbitrage returns(bool); /** * @notice Function to get seller's address * @return Seller's address **/ function seller() public returns(address); /** * @notice Function to get custom type for ESCB9 smart contract * @return Type **/ function type() public returns(bytes); /** * @notice Function to get buyer's address * @return Buyer's address **/ function buyer() public returns(address); /** * @notice Function to get sum for deal * @return Sum of deal in wei **/ function depositedSum() public returns(uint256); /** * @notice Function to get arbitrage's address * @return Arbitrage's address **/ function arbitrage() public returns(address); } 

7 Integration eines Vertrauenssystems und intelligenter Verträge zur Implementierung des ESCB9-Protokolls

Um das Vertrauenssystem der Hierarchie der Brieftaschen mit mehreren Signaturen in Ihrem eigenen Projekt zu verwenden, müssen Sie einen intelligenten Vertrag erstellen, der den ESCB9-Standard implementiert, und einen solchen intelligenten Vertrag an einen der Schiedsrichter anhängen, der keine untergeordneten Brieftaschen hat. Solche Brieftaschen in einer Hierarchie mit mehreren Abonnements werden als "Eingabeknoten" bezeichnet. Alle vorgelagerten Brieftaschen mit mehreren Signaturen werden als "Arbitrierungsknoten" bezeichnet.

8 Beispiele für Verträge, die ESCB9 implementieren

8.1 Smart Contract für den privaten Vermietungsmarkt nach dem Vorbild von AirBnb

 // Don't use this code, it can be not working or contain the vulnerability, for demonstration purpose only pragma solidity ^0.4.21; /// @title rentMyApartmentESCB9 - Allows rent object on market with escrow service. The safe way to do deal for counterparties. /// @author Konstantin Viktorov - <ceo@escrowblock.net> contract rentMyApartmentESCB9 is ESCB9 { // 2018-05-10 18:25 in unix timestamp uint256 constant public checkInTime = 1525965900; // 2018-05-20 18:25 in unix timestamp uint256 constant public checkOutTime = 1526829900; // Coordinates in bytes format. For example 56.865129,35.881540 bytes constant public coordinates = "0x35362e3836353132392c33352e383831353430"; // Google maps link, as example, but better add Url to landing page bytes constant public externalUrl = "0x68747470733a2f2f676f6f2e676c2f6d6170732f6e783563396b6737384170"; /** * Encrypted information, see https://github.com/ethereumjs/ethereumjs-wallet and * https://github.com/pubkey/eth-crypto/blob/master/tutorials/encrypted-message.md * For example you can leave here information about pin-code for smart lock **/ bytes constant private privateInformation = '0x0dfef623523483245687234'; modifier only_before_check_in { require(getNow() < checkInTime); _; } modifier only_after_check_out { require(getNow() > checkOutTime); _; } modifier only_during_renting { require(getNow() > checkInTime && getNow() < checkOutTime); _; } modifier only_not_in_during_renting { require(getNow() < checkInTime && getNow() > checkOutTime); _; } /** * @notice ESCB9 interface * @notice Function to get address of apartment owner * @return Seller's address **/ function seller() public returns(address) { return "0x27a36731337cdee360d99b980b73e24f6e188618"; } /** * @notice ESCB9 interface * @notice Function to get custom type for ESCB9 smart contract * @return Type **/ function type() public returns(bytes) { return "rent"; } /** * @notice ESCB9 interface * @notice Function to get address of renter * @return Buyer's address **/ function buyer() public returns(address) { return "0xb582baaF7e749d6aA98A22355A9d08B4c4d013C8"; } /** * @notice ESCB9 interface * @notice Function to get sum for deal * @return Sum of deal in wei **/ function depositedSum() public returns(uint256) { return 1000000000000000000; //1 ETH in weis } /** * @notice ESCB9 interface * @notice Function to get arbitrage's address * @return Arbitrage's address **/ function arbitrage() public returns(address) { return "0xe91065d8bb2392121a8fbe6a81e79782fbc89dd4"; } /** * @notice ESCB9 interface * @notice Function to approve escrow deal and confirm success * @param Some comment * @return Success of operation **/ function confirm(notice) public onlyArbitrage only_after_check_out returns(bool) { confirmed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to freeze escrow deal * @param Some comment * @return Success of operation **/ function freeze(notice) public onlyArbitrage only_during_renting returns(bool) { frozen(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to dispute escrow deal * @return Success of operation **/ function dispute() public onlyArbitrage only_after_check_out returns(bool) { disputed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to cancel escrow deal and confirm fail * @return Success of operation **/ function cancel() public onlyArbitrage only_not_in_during_renting returns(bool) { canceled(getNow(), notice); } /** * @notice Get current unix time stamp **/ function getNow() constant public returns (uint) { return now; } /** * @notice Get private information when renter will pay deposit **/ function getPrivateInformation() constant isDeposited public returns (bytes) { return privateInformation; } } 

8.2 Ein intelligenter Vertrag für den Austausch einer Kryptowährung gegen Fiat-Geld und zurück in einem dezentralen Modus

Das unten beschriebene Beispiel eines Smart-Vertrags ermöglicht es Ihnen, BTC direkt gegen Fiat-Geld einzutauschen, ohne dass Austauscher und Dienste von Drittanbietern teilnehmen müssen. Der BTC-Verkäufer überträgt den Betrag im Smart-Vertrag auf die Einzahlung in der BTC-Blockchain. Der Käufer überweist nach Bestätigung der Anzahlung durch den Schiedsrichter automatisch den im Vertrag festgelegten Betrag auf das im Vertrag enthaltene Konto oder die Plastikkartennummer. Der Schiedsrichter kann nach Berufung eines der Teilnehmer in die Transaktion eingreifen. Zunächst wird die Anzahlung eingefroren, und wenn die Parteien nicht einvernehmlich zustimmen, wird ein solcher Vertrag mit einer weiteren Lösung über den Fluss der umstrittenen Interaktion bestritten.

 // Don't use this code, it can be not working or contain the vulnerability, for demonstration purpose only pragma solidity ^0.4.21; /// @title p2pExchangeESCB9 - Allows exchanging any cryptocurrencies on fiat money and back, directly between users. The safe way to do deal for counterparties. /// @desc This example shows as exchange fiat money on BTC (forward flow) /// @author Konstantin Viktorov - <ceo@escrowblock.net> contract p2pExchangeESCB9 is ESCB9 { // in minimal decimals, for example, 500.000 rubles is equal 50000000 kopeks uint256 constant public inputAmount = 50000000; // RUR in bytes bytes constant public inputCurrency = "0x525552"; // in minimal decimals, for example, 1 BTC is equal 100000000 satoshi uint256 constant public outputAmount = "100000000"; // BTC in bytes bytes constant public outputCurrency = "0x425443"; // Deposit can be place only before this time const bytes public closeTime = "1526829900"; // use "forward" way, when output currency will be deposited or "backward" if input currency will be deposited uint256 constant public depositWay = "forward"; /** * Encrypted information, see https://github.com/ethereumjs/ethereumjs-wallet and * https://github.com/pubkey/eth-crypto/blob/master/tutorials/encrypted-message.md **/ /** * Encrypted information for placing deposit, for example BTC address **/ bytes private externalDepositAddress = "0x3139333978476346484d6f464b465845564754415761706b3537694e6a3579556b52"; /** * Encrypted information for the amount of deposit, for example for BTC 8 decimals can be added 2-3 chars from 0-9 as pin-code for deal. See more in EscrowBlock WhitePaper * If output amount is equal 100000000, then deposited amount can be 100000123 **/ bytes private externalDepositAmount = "0x5f5e17b"; /** * Encrypted information for sending amount to seller, for example credit card number or bank account, for example 4242424242424242 **/ bytes private externalIncomingAddress = "0xf12765df4c9b2"; modifier only_before_close_time { require(getNow() < closeTime); _; } modifier only_after_close_time { require(getNow() > closeTime); _; } /** * @notice ESCB9 interface * @notice Function to get address of apartment owner * @return Seller's address **/ function seller() public returns(address) { return "0x27a36731337cdee360d99b980b73e24f6e188618"; } /** * @notice ESCB9 interface * @notice Function to get custom type for ESCB9 smart contract * @return Type **/ function type() public returns(bytes) { return "exchange"; } /** * @notice ESCB9 interface * @notice Function to get address of renter * @return Buyer's address **/ function buyer() public returns(address) { return "0xb582baaF7e749d6aA98A22355A9d08B4c4d013C8"; } /** * @notice ESCB9 interface * @notice Function to get sum for deal * @return Sum of deal in minimal decimals **/ function depositedSum() public returns(uint256) { rerurn outputAmount; } /** * @notice ESCB9 interface * @notice Function to get arbitrage's address * @return Arbitrage's address **/ function arbitrage() public returns(address) { return "0xe91065d8bb2392121a8fbe6a81e79782fbc89dd4"; } /** * @notice ESCB9 interface * @notice Function to approve escrow deal and confirm success * @param Some comment * @return Success of operation **/ function confirm(notice) public onlyArbitrage only_after_close_time returns(bool) { confirmed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to freeze escrow deal * @param Some comment * @return Success of operation **/ function freeze(notice) public onlyArbitrage only_after_close_time returns(bool) { frozen(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to dispute escrow deal * @return Success of operation **/ function dispute() public onlyArbitrage only_after_close_time returns(bool) { disputed(getNow(), notice); } /** * @notice ESCB9 interface * @notice Function to cancel escrow deal and confirm fail * @return Success of operation **/ function cancel() public onlyArbitrage only_before_close_time returns(bool) { canceled(getNow(), notice); } /** * @notice Get current unix time stamp **/ function getNow() constant public returns (uint) { return now; } /** * @notice Get private information for buyer when seller sent deposit **/ function getExternalIncomingAddress() constant isDeposited public returns (bytes) { return externalIncomingAddress; } /** * @notice Get private information about amount for seller for sending deposit **/ function getExternalDepositAmount() constant public returns (bytes) { return externalDepositAmount; } /** * @notice Get private information about address for seller for sending deposit **/ function getExternalDepositAddress() constant public returns (bytes) { return externalDepositAddress; } } 

9 Schiedsgerichtsknoten

Um die Arbeit des Vertrauenssystems aufrechtzuerhalten, wird eine Hierarchie von Brieftaschen mit mehreren Signaturen eingeführt. Schiedsgerichtsknoten, dh solche Geldbörsen in der Hierarchie, unter denen sich untergeordnete Geldbörsen befinden, fungieren als Garanten für die Streitbeilegung. Bevollmächtigte für solche Knoten können nur durch eine übergeordnete Hierarchie ernannt werden. Jeder autorisierte Teilnehmer erhält eine Belohnung, indem er Dividenden und Boni für die Arbeit mit umstrittenen Interaktionsströmen verteilt. Die Bonusgröße wird im Konsens festgelegt.
Um den Status eines autorisierten Teilnehmers in einem Schiedsgerichtsknoten zu erhalten, muss eine konsensdefinierte Anzahl von Token an der Adresse eines autorisierten Teilnehmers vorhanden sein.Somit ist ein stabiler Dividendenempfang bei allen Teilnehmern der Schiedsgerichtsknoten gewährleistet. Je höher die Hierarchie einer Brieftasche mit mehreren Signaturen ist, desto mehr Token sollten an der Adresse eines autorisierten Teilnehmers vorhanden sein.

10 Wörterbuch

Ethereum ist eine Open Source-Technologie, mit der Sie eine dezentrale, unveränderliche Transaktionskette erstellen können. Jede Transaktion kann unter bestimmten Bedingungen ausgeführt werden, die in einem Smart-Vertrag festgehalten sind.
Intelligenter Vertrag - geschrieben in Solidity, der in der virtuellen Maschine von Ethereum ausgeführten Logik, mit der Sie die Transaktionslogik erweitern können.
Ein Multi-Signature-Wallet (Arbiter) ist ein spezieller Smart-Vertrag, der von einer Gruppe autorisierter Teilnehmer gesteuert wird, die Transaktionen bestätigen oder stornieren können. Mithilfe des Mechanismus von Brieftaschen mit mehreren Abonnements können Sie eine Kette von Gateways für Transaktionen erstellen und die Ausführung oder Rückerstattung rechtzeitig überwachen.
Eigentümer eines Objekts - ist ein Vermieter, Lieferant, Entwickler eines Softwareprodukts usw. Das heißt, eine Person, die ein Objekt verkauft und letztendlich eine Kaution als Belohnung erhält.
Eigentümer von Geldern - ist ein Mieter, Käufer, Kunde eines Softwareprodukts usw. Das heißt, eine Person, die eine Kaution für ein Objekt hinterlegt, um ein Produkt oder eine Dienstleistung zu kaufen.