
Los contratos multigrado en redes descentralizadas modernas son una herramienta poderosa que le permite proteger de manera simple y confiable los fondos en cuentas colectivas, así como realizar transacciones con varios participantes. Si está interesado en cómo usar dichas direcciones, simplemente tiene que comprender la mecánica de poseerlas y tener una buena idea del orden de las transacciones. Para trabajar con tales direcciones se requiere la participación de varias cuentas.
A pesar del mismo nombre y una lógica de trabajo similar, los algoritmos y métodos internos para interactuar con direcciones protegidas por firma múltiple son bastante diferentes en Bitcoin y Ethereum. Se trata de este dispositivo interno que se discutirá en este artículo.
Hablaremos de dos redes: Bitcoin y Ethereum. En otras cadenas de bloques, el acceso multigrado a los activos de cifrado se puede implementar de una manera completamente diferente.
Introduccion
Supongamos que tenemos la tarea de proteger los fondos del acceso no autorizado a la dirección (cuenta, si la terminología bancaria está más cerca de usted), donde se almacena el dinero de la organización. El acceso a la dirección (la capacidad de crear una transacción desde ella a una externa) está disponible para varias personas, por ejemplo, el contador general, financiero y jefe. Para proteger el dinero, si alguien de esta trinidad se ve obligado a firmar una conclusión, existe un multigrado. En Bitcoin y Ethereum, puede crear una dirección, cuyo retiro de fondos no requiere una, sino varias confirmaciones.
Ahora, cada uno de los tres participantes, que desean crear una transacción de retiro, debe proporcionar su firma confirmando su consentimiento para la transacción. Cuando se recogen suficientes firmas, los fondos se transfieren. Esta lógica se llama multisig: enviar N de M firmas (M> N) para confirmar la operación.
Para redes descentralizadas, multisig es un patrón nativo, ya que cualquier transacción válida enviada a alguna dirección por diseño contiene una firma electrónica creada por la clave secreta del remitente, por lo que casi toda la funcionalidad necesaria para direcciones multisig ya está a bordo de la mayoría de las cadenas de bloques modernas.
Lo más interesante es la dirección multigrado más simple 2/3, cuya conclusión solo es posible por acuerdo de dos de los tres participantes. Tal multisig es capaz de realizar muchas transacciones con tres partes de manera conveniente y segura y resolver problemas cuando dos participantes confían en el tercero para juzgarlos. Casi todos los servicios financieros en los que hay un tercero de confianza se implementan utilizando multisig 2/3. Por ejemplo, tome una carta de crédito: el pagador gana el dinero y no puede tomarlo a menos que convenza al banco (donde no llegaron los documentos de compra) o al destinatario (por su propia voluntad) a aceptarlo. El destinatario tampoco podrá cobrar el dinero si el vendedor no lo devuelve (por su propia voluntad) o si el banco no informa que le han llegado los documentos necesarios y los revisó. En el esquema, el servicio del banco es indecentemente simple: cuando ve un acuerdo sobre la compra de un apartamento, en lugar de llevar la llave a la celda a la tienda, simplemente envía un permiso a una dirección multigrado.
Las tareas de contabilidad y pago de servicios también gravitan hacia multisig 2/3: a menudo requiere que un tercero decida si el servicio se prestó y en qué medida. Multisig, donde una de las tres firmas pertenece a la organización, que finalmente decide si el servicio se prestó o no (por ejemplo, a la corte), significa que la corte, habiendo decidido a favor de una de las partes, simplemente firma su decisión y envía la transacción, desbloqueando automáticamente los fondos para el lado ganador. Para servicios B2C como Uber o AirBnB, el multisig, aunque implícitamente, es el patrón de trabajo principal: cuando se presta el servicio, es la firma de la solicitud del servicio la que inicia el envío de fondos del cliente al conductor o al propietario del apartamento.
En general, un multisig implementado convenientemente, como un rifle de asalto Kalashnikov: barato y alegre, es adecuado para usar en casa y por tarifas de millones de dólares. Y en la cadena de bloques, todo esto es "sin registro y SMS" (desde el punto de vista de la seguridad, esto, por cierto, es una tesis bastante seria, si lo piensas).
Consideraremos dos blockchains: Bitcoin y Ethereum. Debo decir que el dispositivo multigrado interno en ellos es bastante diferente, todo funciona de manera diferente. Pero no nos adelantemos a nosotros mismos.
Bitcoin multisig
Bitcoin en realidad no es tan simple como parece a muchos. Su diseño le permite implementar esquemas livianos y al mismo tiempo muy seguros para obtener acceso a fondos. Bueno, agrego que, puramente en mi opinión personal, las estructuras y algoritmos en Bitcoin están bien pensados, son óptimos y simplemente hermosos. La traducción estándar de bitcoins X de una dirección a otra es solo el tipo de transacción predeterminado, la punta del iceberg de las capacidades potenciales de Bitcoin. La transacción predeterminada para traducir BTC desde el punto de vista del código es el multisig 1/1 más simple: para usar X bitcoins de la dirección a1, debe adjuntar a la transacción una firma electrónica creada usando una clave secreta que pertenece a la dirección a1. Veamos la estructura de una transacción de Bitcoin y profundicemos un poco más en cómo funciona.

Hay un requisito en Bitcoin: todos los BTC almacenados en una determinada dirección siempre se gastan como un todo. Es decir, habiendo confirmado su derecho a tener una dirección, la transacción gasta todo el saldo, distribuyéndolo en varias salidas. En la vida real, dejar la diferencia entre entradas y salidas al minero como comisión, pero para este artículo esto no es significativo.
Imagina la situación. Vasya recibió 50 BTC. Vasya quiere enviar a Peta 0.5 BTC. Para hacer esto, debe gastar los 50 BTC. Para obtener un cambio, Vasya toma una entrada (50 BTC) y crea dos salidas:
- 0.5 BTC a la dirección de Petit;
- 49.5 BTC a una de sus propias direcciones.
Cuando dicen "Vasya firma la transacción", esto no es del todo exacto para Bitcoin. Vasya firma todas las entradas en la transacción, y cada entrada es una dirección de bitcoin separada, y cada una de ellas necesita una clave secreta correspondiente. Supongamos que Vasya tiene tres direcciones a las que tres de sus amigos enviaron 0.1 BTC cada una. Para gastar 0.25 BTC, Vasya tendrá que firmar tres entradas (cada una de 0.1) y formar dos salidas (0.25 a la dirección del destinatario y 0.05 a sí mismo como un cambio). Tal esquema permite, en particular, nunca usar la misma dirección dos veces y devolver el cambio cada vez a una nueva. Algunas billeteras, como Electrum, permiten al propietario elegir la estrategia para reutilizar direcciones, más privadas (cada vez que una nueva dirección) o más simples, pero con direcciones permanentes (este esquema es más conveniente si recurre a transacciones regulares complejas). Les recuerdo que la diferencia entre la suma de entradas y salidas es una comisión para el minero: simple y confiable.
Ahora, en lugar de "Vasya firma la transacción", digo, "Vasya firma la entrada". Pero deliberadamente perdí algunos puntos más, para no complicar el esquema general. El hecho es que las direcciones en Bitcoin no son una clave pública en su forma más pura, sino su hash (dos veces un hash con varios bytes de servicio y versión, detalles en el artículo de Bitcoinwiki), es decir, en una transacción normal, el remitente ni siquiera conoce la clave pública del destinatario. Por lo tanto, Vasya, al firmar la entrada, además de la firma en sí, presenta Bitcoin Script con su propia clave pública, revelándola. Naturalmente, conociendo la clave pública, puede generar fácilmente una dirección de Bitcoin.
Además de firmar entradas, Vasya también establece una condición para cada salida, cómo gastar BTC de esta salida en particular. Pero los "requisitos" le fueron proporcionados por el que recibirá bitcoins: le preocupa cómo gastará su BTC. Este es un punto extremadamente importante. La dirección de Bitcoin contiene un hash del código que decidirá si se permite BTC desde esta dirección.
Si aún busca analogías, entonces Vasya para cada salida (que recibió por aquellos que reciben BTC) adjuntará datos que respondan a la pregunta "¿Qué código y en qué datos debe regresar para que el firmante sea considerado el propietario de esta salida?" . Aquí hay otra analogía para los pitonistas: puede imaginar que cada salida contiene una función lambda que, ejecutada por Petya, quien le proporcionó argumentos, devolverá verdadero o falso. Si se devuelve verdadero, entonces Petya puede usar la salida como entrada para transacciones posteriores. En la versión predeterminada, el programa puede tomar dos argumentos proporcionados por Petya, la firma de salida y la clave pública de Petin, y verificar la firma. Si se devuelve verdadero, Petya tiene derecho a generar y puede gastarlo; por lo tanto, la transacción es válida. No es necesario profundizar en el marco de este artículo en Script, pero es extremadamente deseable. Por cierto, canjear script: este es el contrato muy inteligente, es decir, una regla formal por la cual el derecho a BTC pasa de una dirección a otra. Los clientes de la red, durante la transacción, ejecutan cada script en cada transacción, verificando si es válido. Si es válido: desperdicio válido e innegable de bitcoins de una dirección específica.
Aquí está el primer excelente artículo sobre este tema, recomiendo leerlo, todo el mecanismo sin procesar con ejemplos en Python está perfectamente pintado: Bitcoins de la manera difícil: usando el protocolo sin procesar de Bitcoin . Y aquí hay otro: Bitcoin en pocas palabras: transacción .
Volvamos a multisig 2/3, señalando que la transacción habitual con la transferencia de bitcoins también se puede considerar como multisig 1/1. Supongamos que Petya quiere que Vasya simplemente le transfiera BTC. Petya le da a Vasya la dirección a la que se cose el hash del script predeterminado, y Bitcoins puede recoger los bitcoins de esta dirección al proporcionar un código de verificación de firma estándar y la firma en sí. Tales direcciones "tradicionales" en Bitcoin comienzan con el número 1 (unidad). Las direcciones en las que se cose el código "no convencional" (comprobando la secuencia de comandos multigrado) se denominan pago a secuencia de comandos y comienzan con 3 (triples).
Bitcoin nos permite crear una dirección en la que se coserá el hash de NUESTRO PROPIO script de canje. Después de todo, este es nuestro problema, ya que luego gastaremos nuestro BTC, y no el envío. No nos importa quién transfiera los bitcoins a una dirección, pero es importante que cuando queramos gastarlos, tengamos que proporcionar un código correspondiente a la dirección. Es decir, al pedirme que transfiera BTC a una dirección de pago a secuencia de comandos, me comprometo a proporcionar la secuencia de comandos más adelante, en una transacción que utiliza esta entrada.
Según la documentación, para el código multigrado de este tipo se utiliza:
----------------------------------------------------------- Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL Signature script: <sig> [sig] [sig...] <redeemScript> -----------------------------------------------------------
( Artículo continuo sobre script y multisig )
Necesitamos un script para que todas las firmas necesarias se presenten inmediatamente en la transacción de gastos. Si, por ejemplo, nuestro multisig 2/3 contiene las direcciones de tres participantes (CEO, jefe de contabilidad y administrador del sistema) y las claves secretas para las firmas están en sus computadoras por separado, entonces para formar una transacción de gasto, el administrador del sistema deberá:
- generar una transacción de gasto;
- crea tu propia firma;
- transfiera el contenido de la transacción al segundo firmante (por ejemplo, vaya al departamento de contabilidad o al general con una unidad flash);
- pedirle al segundo firmante que agregue una firma a la transacción;
- Enviar una transacción a la red con dos de las tres firmas.
Esta no es una manera muy simple, pero le permite usar como uno de los firmantes una computadora que está completamente desconectada de la red y no se garantiza que combine la clave secreta. En este caso, el retiro de fondos es completamente "manual", lo cual es bastante bueno para grandes cantidades. Siglo 21, amigos, ahora está de moda poner una computadora portátil cero en una caja fuerte sin conexión de red y con el único software instalado: una billetera Bitcoin.
Ethereum multisig
La implementación de multisig en Ethereum es muy diferente de la de Bitcoin debido al diseño diferente de los algoritmos internos de la red del cliente, pero hay paralelos. En Ethereum, una transacción especial del tipo "create_contract" crea una dirección en la red a la que está vinculado el código para un contrato en particular. Esta dirección también tiene un balance de éter. Si envía éter allí, la dirección "lo equilibrará". Y viceversa, si envía éter desde la dirección, "se eliminará del balance".
Inmediatamente arrojo algunas analogías bastante precisas para comprender una cocina muy simple y lógica. Si nos olvidamos del consenso y cómo los nodos actualizan la cadena de bloques, y consideramos la cadena de bloques como un almacenamiento abstracto, entonces la colocación del contrato se puede comparar, por ejemplo, con la creación de instancias de un objeto, es decir, convertir la clase en un objeto real en RAM. En una analogía, la memoria es una cadena de bloques, y el código de clase es un código de contrato. Después de la instanciación, el objeto (contrato) recibe su propia dirección en la "memoria", y la red conoce la interfaz, presentada en la forma descrita en la clase de métodos.
Las transacciones que llegan a la dirección en dicho esquema son métodos de escritura, cambian el estado interno del objeto del contrato. Cualquier cliente de la red ejecuta métodos-lectores que simplemente leen datos del estado del contrato, porque está seguro de que su copia del objeto es correcta y confirmada por el consenso de los productores de bloques. También es importante comprender que el código del contrato se ejecuta cuando el minero "aplica" la transacción que llegó al contrato existente, y en nuestra versión simplemente llama a uno de los métodos del contrato con argumentos integrados en la transacción.
Bueno, dado que el contrato tiene un estado interno (campos de objeto en nuestra analogía), puede implementar multiseño sin la necesidad de enviar firmas en una transacción. Creamos un contrato, en él codificamos las direcciones de los firmantes, cuando llegan las transacciones de retiro: transferimos el contrato secuencialmente al estado de espera del número requerido de confirmaciones. Si estamos hablando de multisig 2/3, podría verse así:
- el administrador del sistema implementará un contrato multigrado en la red y pondrá las direcciones del director general y el contador principal en la misma;
- los clientes satisfechos envían toneladas de éter al contrato;
- el contador principal va a hacer un gran pago y envía una transacción al contrato con el deseo de transferir un poco de éter a una dirección externa;
- multisig-contract entra en el estado "Espero N confirmaciones", en nuestro caso uno es suficiente
- el CEO quiere ayudar al contador principal, pero olvidó en qué computadora portátil se necesita la clave secreta;
- el administrador del sistema envía una transacción: confirmación del retiro de fondos al contrato;
- El contrato, después de haber aceptado la transacción del administrador del sistema, entiende que se han marcado las N confirmaciones necesarias y envía la transmisión a la dirección ordenada por el contador principal, mientras regresa al estado de simple recepción de fondos.
Muchas cosas se pueden implementar de manera diferente dependiendo de la implementación del contrato multigrado. Esto se aplica al almacenamiento de pedidos pendientes de retiro, el intervalo de tiempo para esperar el retiro, restricciones convenientes. Por ejemplo, puede permitir el retiro de cantidades hasta cierto límite sin firma múltiple y solicitar confirmación si se excede el límite.
Hay varias opciones para el código de contrato de billetera multigrado; puede encontrarlas fácilmente. El más oficial de ellos es este . Hay muchas más modificaciones de los contratos multigrado, así como los contratos que son multigrado, pero ni siquiera lo saben, porque cualquier contrato con varios roles en el sentido filosófico es multigrado.
Conclusión
Examinamos el esquema de operación de uno de los ladrillos más importantes para construir sistemas de contratos complejos y organizar transacciones multilaterales. ¿Dónde está la manera más fácil de sentir en vivo las direcciones multigrado?
- para Bitcoin: la billetera Electrum tiene instrucciones detalladas paso a paso con capturas de pantalla sobre cómo crear y configurar una dirección multigrado y cómo usarla. Simplemente busque Electrum multisig;
- para Ethereum: hay una sección de Contratos en la billetera de billetera estándar de Ethereum, y allí puede crear fácilmente multisig. Además, multisig seguramente se presentará en muchas formas en plataformas para lanzar contratos estándar, por ejemplo, ya tenemos uno en nuestro Smartz.io .
Como puede ver, en la cadena de bloques, estos esquemas son muy tecnológicos y simples, así que úselos para su placer y proteja su riqueza criptográfica correctamente.