Geekly articles weekly

Jerarquía de billetera con firma múltiple (sistema de confianza)

Este texto describe la abstracción de un sistema de confianza, que le permite integrar servicios de custodia en cualquier área de las relaciones económicas.
Depositar fondos es una parte fundamental de cualquier transacción. Si las contrapartes no conocen información confiable entre sí, entonces aumenta el riesgo de fraude. Este enfoque le permite programar en una red descentralizada un modelo de resolución de disputas, un modelo para realizar transacciones automáticas, transacciones seguras, etc. Además, dicho modelo de un sistema de confianza está abierto. Todas las transacciones realizadas con la participación de la jerarquía de billetera de suscripción múltiple nos permiten verificar la calificación de la contraparte y también protegernos de esquemas fraudulentos de nuevos participantes en las relaciones económicas.

Contenido


1 Introducción
2 Descripción de una billetera con firma múltiple
3 formas de construir una jerarquía de billetera
4 Interfaz de jerarquía de billetera de varios días
5 flujos de interacción
5.1 Flujo de interacción estándar
5.2 Flujo de interacción segura
5.3 Flujo controvertido de interacción
6 Protocolo ESCB9
7 Integración de un sistema de confianza y contratos inteligentes que implementan el protocolo ESCB9
8 Ejemplos de contratos que implementan ESCB9
8.1 Contrato inteligente para el mercado de alquiler privado, siguiendo el ejemplo de AirBnb
8.2 Un contrato inteligente para el intercambio de cualquier criptomoneda por dinero fiduciario y de vuelta en un modo descentralizado
9 nodos de arbitraje
10 Diccionario

1. Introducción


El principal problema para los servicios de custodia es la creación de relaciones de confianza entre todos los participantes. Además, los propios participantes no deben ser necesariamente conocidos por cada sujeto de las relaciones. Para resumir todos los casos, tendremos en cuenta que todos son anónimos. Para un sistema de relaciones tan confiable, es importante regular las relaciones de los nuevos participantes con los antiguos. Los antiguos participantes ya tienen una cierta calificación en el sistema de relaciones y, por lo tanto, causan más confianza. Como nadie conoce a nadie en el sistema de confianza, esto causa problemas con la verificación de la calificación anterior. Este documento describe el sistema de confianza basado en billeteras criptográficas de suscripción múltiple. Tal sistema se puede programar en un contrato inteligente. En vista de la amplia distribución de la plataforma Ethereum, elegiremos esta plataforma como la plataforma para describir todos los contratos inteligentes en este documento.

2. Descripción de una billetera con firma múltiple


Una abstracción que le permite confirmar o cancelar transacciones solo si se llega a un consenso entre los participantes autorizados para tomar tal decisión se llama billetera con firma múltiple. Una transacción en este contexto es una operación atómica programada para ejecutar un método en otro o el mismo contrato inteligente.

La interfaz para el contrato inteligente de tal abstracción se puede representar como:

  1. el constructor acepta las direcciones de los miembros fundadores y el número de confirmaciones mínimas requeridas para las transacciones
    constructor(address[]:members, uint256:requiredConfirmationCount)

  2. Interfaz de participante autorizado
    1. obtener una lista de participantes
       static getMembers() -> address[]:address

    2. ver la dirección del miembro
       static getMember(uint256:indexNumber) -> address:address

    3. verificación de dirección para membresía
       static isMember(address:address) -> bool:value

    4. obtener el número máximo de participantes para la billetera
       static getMaxMemberCount() -> uint256:value

    5. Confirmación de consenso mínimo
       static getRequiredConfirmationCount() -> uint256:value

    6. evento de agregar un nuevo miembro
       event MemberAddition() -> address:member

    7. evento de eliminación de miembros
       event MemberRemoval() -> address:member

    8. el evento de cambio requirió el número de confirmaciones para ejecutar
       event RequiredConfirmationCountChange() -> uint256:count

    9. agregar miembro
       execute addMember(address:member) -> void:value

    10. eliminación de miembros
       execute removeMember(address:member) -> void:value

    11. reemplazo de miembros
       execute replaceMember(address:currentMember, address:newMember) -> void:value
    12. cambio en el número de confirmaciones obligatorias para ejecución
       execute changeRequiredConfirmationCount(uint256:count) -> void:value


  3. Interfaz de transacción
    1. verificación de la confirmación de la transacción en la dirección del participante
       static getConfirmationByAddress(uint256:indexNumber, address:addressMember) -> bool:value

    2. obtener información de una transacción
       static getTransactionInfo(uint256:indexNumber) -> [address:destination, uint256:value, bytes:data, bool:executed]
    3. obtener el número total de transacciones en esta billetera
       static getTransactionCount() -> uint256:value
    4. recibir el estado de confirmación de la transacción
       static isConfirmed(uint256:transactionId) -> bool:value
    5. recibir el número de confirmaciones
       static getConfirmationCount(uint256:transactionId) -> uint256:count
    6. obteniendo el número de transacciones por tipo
       static getTransactionCount(bool:pending, bool:executed) -> uint256:count
    7. obtener la lista de participantes que confirmaron la transacción
       static getConfirmations(uint256:transactionId) -> address[]:confirmations
    8. obtener una lista de ID de transacción por tipo en un cierto período de tiempo
       static getTransactionIds(uint256:from, uint256:to, bool:pending, bool:executed) -> uint256[]:transactionIds
    9. evento de confirmación de transacción del partido
       event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp]
    10. evento de retiro de confirmación del participante antes de la transacción
       event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp]
    11. evento de agregar transacción de cola
       event Submission() -> [uint256:transactionId]
    12. evento de ejecución de transacción
       event Execution() -> [uint256:transactionId]
    13. evento de error de transacción
       event ExecutionFailure -> [uint256:transactionId]
    14. evento de reposición de billetera
       event Deposit -> [address:sender, uint256:amount]
    15. miembro agregando transacción
       execute submitTransaction(address:destination, uint256:value, bytes:data) -> uint256:transactionId
    16. confirmación de la transacción por parte del participante
       execute confirmTransaction(uint256:transactionId) -> void:value
    17. retiro de la confirmación por parte del participante
       execute revokeConfirmation(uint256:transactionId) -> void:value
    18. transacción manual
       execute executeTransaction(uint256:transactionId) -> void:value



3 formas de construir una jerarquía de billetera


Hay dos formas principales de construir un sistema de confianza. Vertical y horizontal. La forma horizontal de construir implica la creación de una lista de billeteras secundarias por parte de un padre principal. La forma vertical de construir implica una cadena que consiste en billeteras infantiles con referencia a los padres. En este caso, la billetera principal puede ser hija de otra billetera principal.
Como vemos, la ruta de construcción horizontal puede ser una subespecie de la ruta de construcción vertical. Por lo tanto, además dejamos este enfoque desatendido.

4 Interfaz de jerarquía de billetera de varios días


Para construir un sistema de confianza, es necesario expandir la interfaz simple de la billetera de múltiples firmas descrita anteriormente, agregando mecanismos para regular la jerarquía y la ejecución automática de confirmaciones, así como la posibilidad de una ejecución retrasada.
  1. El constructor acepta la dirección de la billetera principal, las direcciones de los miembros fundadores, el número de confirmaciones mínimas requeridas para las transacciones, el tiempo estándar para las confirmaciones automáticas en segundos
     constructor(address:parent, address[]:members, uint256:requiredConfirmationCount, uint256:standardTimeAutoConfirmation)

  2. Interfaz de miembro
    1. obtener una lista de participantes
       static getMembers() -> address[]:address

    2. función para ver la dirección del participante
       static getMember(uint256:indexNumber) -> address:address

    3. verificación de dirección para membresía
       static isMember(address:address) -> bool:value

    4. obtener el número máximo de participantes de la billetera
       static getMaxMemberCount() -> uint256:value

    5. Confirmación de consenso mínimo
       static getRequiredConfirmationCount() -> uint256:value

    6. evento de agregar un nuevo miembro
       event memberAddition() -> address:member

    7. evento de eliminación de miembros
       event memberRemoval() -> address:member

    8. el evento de cambio requirió el número de confirmaciones para ejecutar
       event requiredConfirmationCountChange() -> uint256:count

    9. agregar miembro
       execute addMember(address:member) -> void:value

    10. eliminación de miembros
       execute removeMember(address:member) -> void:value

    11. reemplazo de miembros
       execute replaceMember(address:currentMember, address:newMember) -> void:value

    12. cambio en el número de confirmaciones obligatorias para ejecución
       execute changeRequiredConfirmationCount(uint256:count) -> void:value


  3. Interfaz de jerarquía
    1. obtener una lista de billeteras para niños
       static getChildren() -> address[]:wallets

    2. verificar si la dirección de la billetera es hija de la actual
       static isChild() -> bool:value

    3. La verificación de si la dirección de la billetera es parental a la actual se realiza a través de isChild al contrastarla.
    4. evento adjunto de billetera afiliada
       event childAttachment() -> [address:address,uint256:timeStamp]

    5. evento de eliminación de billetera infantil
       event childRemoval() -> [address:address,uint256:timeStamp]

    6. colocar una billetera infantil
       execute attachChild(addres:child) -> void:value

    7. eliminar billetera infantil
       execute removeChild(address:address) -> void:value

    8. cambiar una billetera infantil a otra
       execute replaceChild(address:newAddress) -> void:value


  4. Interfaz de transacción
    1. verificar el estado de la transacción
       static getTransactionStatus(uint256:transactionId) -> enum:{submitted,completed,frozen,disputed,reverted}

    2. verificar el estado de la transacción para el cumplimiento
       static isTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> bool:value

    3. verificación de la confirmación de la transacción en la dirección del participante
       static getConfirmationByAddress(uint256:transactionId, address:addressMember) -> bool:value

    4. obtener información de una transacción
       static getTransactionInfo(uint256:transactionId) -> [address:destination, uint256:value, bytes:data, bool:executed]

    5. obtener el número total de transacciones en la billetera
       static getTransactionCount() -> uint256:value

    6. recibir el estado de confirmación de la transacción
       static isConfirmed(uint256:transactionId) -> bool:value

    7. recibir el número de confirmaciones
       static getConfirmationCount(uint256:transactionId) -> uint256:count

    8. obteniendo el número de transacciones por tipo
       static getTransactionCount(bool:pending, bool:executed) -> uint256:count

    9. obtener la lista de participantes que confirmaron la transacción
       static getConfirmations(uint256:transactionId) -> address[]:confirmations

    10. obtener tiempo para la confirmación automática
       static getTimeAutoConfirmation(uint256:transactionId) -> uint256:timestamp

    11. obtener una lista de ID de transacción por tipo en un cierto período de tiempo
       static getTransactionIds(uint256:from, uint256:to, bool:pending, bool:executed) -> uint256[]:transactionIds

    12. evento de confirmación de transacción del partido
       event Confirmation() -> [address:sender, uint256:transactionId, uint256:timeStamp]

    13. evento de confirmación de transacción automática
       event AutoConfirmation() -> [uint256:transactionId, uint256:timeStamp]

    14. evento de retiro de confirmación del participante antes de la transacción
       event Revocation() -> [address:sender, uint256:transactionId, uint256:timeStamp]

    15. evento de agregar transacción de cola
       event Submission() -> [uint256:transactionId]

    16. evento de ejecución de transacción
       event Execution() -> [uint256:transactionId]

    17. evento de error de transacción
       event ExecutionFailure -> [uint256:transactionId]

    18. cambio de estado de transacción a evento congelado
       event TransactionFrozen -> [uint256:transactionId]

    19. cambio de estado de transacción a evento controvertido
       event TransactionDisputed -> [uint256:transactionId]

    20. cambio del estado de la transacción al evento devuelto
       event TransactionReverted -> [uint256:transactionId]

    21. evento de reposición de billetera
       event Deposit -> [address:sender, uint256:amount]

    22. agregar transacción para ejecutar
       execute submitTransaction(address:destination, uint256:value, uint256:TimeAutoConfirmation, bytes:data) -> uint256:transactionId

    23. confirmación de la transacción
       execute confirmTransaction(uint256:transactionId) -> void:value

    24. confirmación de revocación
       execute revokeConfirmation(uint256:transactionId) -> void:value

    25. cambiar el estado de la transacción a congelado
       execute setTransactionStatus(uint256:transactionId, uint256:enumStatusNumber) -> void:value

    26. transacción manual
       execute executeTransaction(uint256:transactionId) -> void:value


  5. Gestión de calificaciones
    1. obtener una calificación en
       static getRatingByAddress(address:agent) -> [uint256:negativeRating, uint256:positiveRating, uint256:countRatingRecords]

    2. Obtener el historial de calificación por dirección y número de serie
       static getRatingRecordForAddress(address:agent, uint256:indexNumber) -> void:value

    3. evento de agregar un registro a la calificación en
       event RatingRecordAdded -> [address:author, address:agent, bytes32:smartContractAddress, bool:positiveOrNegative, uin256:ratingNumber, bytes:comment, uint256:indexNumber]

    4. agregar registro a la calificación para la dirección
       execute addRatingRecord(address:agent, bytes32:smartContractAddress, bool:positiveOrNegative, uin256:ratingNumber, bytes:comment) -> void:value


  6. Integración con el protocolo ESCB9
    1. verificar en la dirección si el contrato inteligente adjunto a esta billetera es un contrato inteligente con implementación de ESCB9
        static isAttachedESCB9SmartContract(address:smartContract) -> bool:result

    2. verificar el estado del depósito para un contrato inteligente con ESCB9 adjunto a esta billetera
        static getDepositStatusForESCB9SmartContract(address:smartContract) -> enum:{awaiting,founded,returned}

    3. evento de adjuntar un contrato inteligente con la implementación de la billetera ESCB9
       event AttachingESCB9SmartContract -> [address:smartContract]

    4. evento de depósito para contrato inteligente con implementación adjunta de billetera ESCB9
       event ConfirmationForDepositESCB9SmartContract -> [address:smartContract, uint256:sum, bytes:notice]

    5. adjuntar un contrato inteligente con la implementación de ESCB9 a la billetera
       execute attachESCB9SmartContract(address:smartContract) -> void:value

    6. confirmación de depósito para contrato inteligente con implementación de ESCB9. Si el depósito está en el sistema externo, el aviso tendrá una etiqueta. Si el depósito está en ETH, el monto del depósito se envía cuando se ejecuta el método.
       execute fundDepositForESCB9SmartContract(address:smartContract, uint256:sum, bytes:notice) -> void:value




5 flujos de interacción


Cualquier contrato inteligente puede integrarse en la jerarquía de billeteras con múltiples firmas. Dicha integración tendrá flujos de interacciones. En términos generales, distinguimos varios tipos de flujos:
  • Estándar . De esta forma, la transacción se realiza automáticamente. Sin la participación de miembros autorizados de la jerarquía de billetera.
  • Protegido De esta forma, el tiempo de transacción se puede aumentar del estándar para la confirmación automática del tiempo al necesario. En este caso, es necesaria la participación de miembros autorizados de la jerarquía de billetera.
  • Controvertido De esta forma, el participante de la transacción puede congelar la transacción. En este caso, la participación de los miembros autorizados de la jerarquía de billetera es necesaria para generar consenso.

Cada billetera en el sistema de confianza tiene un número de participantes plenipotenciarios, que emiten un veredicto. Para un razonamiento simple, combinaremos a todos los participantes autorizados en la billetera en un solo concepto: el árbitro .

5.1 Flujo de interacción estándar


Para simplificar la presentación, traemos los conceptos de bienes y servicios al concepto del objeto de transferencia (objeto), y el concepto de dinero fiduciario, criptomonedas al concepto de medios de transferencia (medios).
La contraparte, el propietario del objeto, hace un trato con la contraparte, el propietario de los fondos, con el propósito de intercambiar. En este caso, el propietario del objeto crea un contrato de custodia inteligente mediante el envío de una transacción estandarizada a una de las billeteras autorizadas en la jerarquía de billeteras con múltiples firmas. En este caso, la transacción es registrada por un tercero como un sistema de confianza. Para cada transacción, se determina el tiempo estándar para su ejecución. La contraparte, el propietario de los fondos, realiza un depósito en la transacción transfiriendo fondos al sistema de fideicomiso. Después de eso, el propietario del objeto transfiere el objeto al propietario de los fondos. El propietario de los fondos verifica la calidad del objeto. Si antes del final del tiempo para la transacción, no confirmó la calidad, los fondos se transfieren al propietario del objeto como parte de la transacción. Ambas contrapartes se otorgan calificaciones de comodidad. Por lo tanto, el propietario de los fondos puede cambiar el flujo de interacción hasta que se complete la transacción. Después de la transferencia de fondos al propietario del objeto, el propietario de los fondos puede solicitar una cartera superior en el nivel de la jerarquía para resolver disputas dentro del tiempo especificado por la regulación. Después de este tiempo, las calificaciones de la transacción se aplican a ambas partes y la transacción se vuelve irrevocable.

5.2 Flujo de interacción segura


Si, por alguna razón fuera del control de las contrapartes, la fecha límite para la transacción debe extenderse, entonces, por acuerdo de las partes, la billetera jerárquica de múltiples firmas (árbitro) puede cambiar el tiempo asignado para la transacción. Después de cambiar el tiempo, el flujo de interacción asignado a la transacción vuelve al nivel lógico del flujo estándar.

5.3 Flujo controvertido de interacción


Si la calidad del objeto durante la transacción no es adecuada para la contraparte, el propietario de los fondos que aporta al sistema de fideicomiso de la jerarquía de billeteras con firma múltiple, la transacción puede congelarse. En este caso, el depósito no se transfiere a la contraparte, el propietario del objeto, hasta que se emita un veredicto sobre la transacción. El titular de los fondos debe proporcionar evidencia sustancial al árbitro de la transacción. Después de eso, el árbitro emite un veredicto a favor de una de las contrapartes. Si alguna de las partes en la transacción no está satisfecha con el veredicto, se convierte en una billetera más alta en el orden en la jerarquía de las billeteras con múltiples firmas. Una vez aprobadas todas las instancias de jerarquía, cualquiera de las partes puede solicitar un voto público. Esta medida excepcional solo puede ser asignada por un monedero absoluto.

6 Protocolo ESCB9


Un ejemplo del protocolo ESCB9 en Solidity como un contrato inteligente abstracto (el protocolo está en desarrollo y está sujeto a cambios)
 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 Integración de un sistema de confianza y contratos inteligentes que implementan el protocolo ESCB9


Para usar el sistema de confianza de la jerarquía de billeteras con múltiples firmas en su propio proyecto, debe crear un contrato inteligente que implemente el estándar ESCB9 y adjuntar dicho contrato inteligente a uno de los árbitros que no tiene billeteras subsidiarias. Tales billeteras en una jerarquía de suscripción múltiple se denominan "nodos de entrada". Todos los monederos de firma múltiple en sentido ascendente se denominan "nodos de arbitraje".

8 Ejemplos de contratos que implementan ESCB9


8.1 Contrato inteligente para el mercado de alquiler privado, siguiendo el ejemplo de 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 Un contrato inteligente para el intercambio de cualquier criptomoneda por dinero fiduciario y de vuelta en un modo descentralizado


El ejemplo de un contrato inteligente que se describe a continuación le permite intercambiar BTC por dinero fiduciario directamente, sin la participación de intercambiadores y servicios de terceros. El vendedor de BTC transfiere el monto del contrato inteligente al depósito en la cadena de bloques de BTC. El comprador, después de confirmar el depósito por el árbitro, transfiere automáticamente el monto estipulado en el contrato a la cuenta o al número de tarjeta de plástico incluido en el contrato. El árbitro puede intervenir en el proceso de transacción después de la apelación de uno de los participantes. Inicialmente, el depósito se congelará y si las partes no acuerdan por consenso, dicho contrato se disputará con una resolución adicional sobre el flujo de interacción disputada.
 // 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 nodos de arbitraje


Para mantener el trabajo del sistema de confianza, se introduce una jerarquía de billeteras con múltiples firmas. Los nodos de arbitraje, es decir, tales billeteras en la jerarquía que tienen billeteras subsidiarias debajo de ellas, actúan como garantes de la resolución de disputas. Los plenipotenciarios para tales nodos solo pueden ser designados por una jerarquía superior. Cada participante autorizado recibe una recompensa al distribuir dividendos y bonos por trabajar con flujos de interacción en disputa. El tamaño del bono se determina por consenso.
Para obtener el estado de un participante autorizado en un nodo de arbitraje, es necesario tener una cantidad de tokens definida por consenso en la dirección de un participante autorizado.Por lo tanto, se garantiza la recepción estable de dividendos por todos los participantes de los nodos de arbitraje. Cuanto más alta sea la jerarquía de una billetera con múltiples firmas, los tokens más necesarios deben estar presentes en la dirección de un participante autorizado.

10 Diccionario


Ethereum es una tecnología de código abierto que le permite crear una cadena de transacciones descentralizada e inmutable. Cada transacción se puede realizar con ciertas condiciones registradas en un contrato inteligente.
Contrato inteligente : escrito en Solidity, la lógica ejecutada en la máquina virtual Ethereum, que le permite expandir la lógica de transacción.
Una billetera con firma múltiple (árbitro) es un contrato inteligente especial controlado por un grupo de participantes autorizados que pueden confirmar o cancelar transacciones. Usando el mecanismo de billeteras de múltiples suscripciones, puede crear una cadena de puertas de enlace para transacciones y monitorear oportunamente la ejecución o el reembolso.
Propietario de un objeto: es un propietario, proveedor, desarrollador de un producto de software, etc. Es decir, una persona que vende un objeto y finalmente recibe un depósito como recompensa.
Propietario de fondos : es un inquilino, comprador, cliente de un producto de software, etc. Es decir, una persona que deposita en un objeto para comprar un producto o servicio.

Source: https://habr.com/ru/post/es412655/

More articles:


All Articles