Neste artigo, analizaremos que son os contratos intelixentes, cales son, coñeceremos diferentes plataformas de contratos intelixentes, as súas características e tamén discutiremos como funcionan e que vantaxes poden aportar. Este material será moi útil para os lectores que non estean ben familiarizados co tema dos contratos intelixentes, pero queiran achegarse a entendelo.
Contrato regular vs. contrato intelixente
Antes de afondar nos detalles, poñamos un exemplo das diferenzas entre un contrato normal, que se especifica en papel, e un contrato intelixente, que se representa dixitalmente.
Como funcionaba isto antes da chegada dos contratos intelixentes? Imaxina un grupo de persoas que queren establecer determinadas regras e condicións para a distribución de valores, así como un determinado mecanismo para garantir a implantación desta distribución segundo as regras e condicións dadas. Despois reuníanse, elaboraban un papel no que anotaban os seus datos identificativos, os termos, os valores implicados, datalos e asinábanos. Este contrato tamén foi certificado por unha persoa de confianza, como un notario. Ademais, estas persoas foron en diferentes direccións coa súa copia en papel de tal contrato e comezaron a realizar algunhas accións que poderían non corresponder co propio contrato, é dicir, fixeron unha cousa, pero en papel certificábase que debían facer algo. completamente diferente. E como saír desta situación? De feito, un dos membros do grupo ten que levar este papel, levar algunhas probas, levalas aos tribunais e lograr o cumprimento entre o contrato e as accións reais. Moitas veces, é difícil lograr unha implementación xusta deste contrato, o que leva a consecuencias desagradables.
Que se pode dicir dos contratos intelixentes? Combinan tanto a posibilidade de redactar os termos do contrato como o mecanismo para a súa estrita implementación. Se se establecen as condicións e se asina a correspondente transacción ou solicitude, unha vez aceptada esa solicitude ou transacción xa non é posible modificar as condicións nin afectar á súa execución.
Hai un validador ou unha rede enteira, así como unha base de datos que almacena todos os contratos intelixentes que foron enviados para a súa execución por estrita orde cronolóxica. Tamén é importante que esta base de datos conteña todas as condicións de activación para executar o contrato intelixente. Ademais, debe ter en conta o propio valor cuxa distribución se describe no contrato. Se isto se aplica a algunha moeda dixital, esta base de datos debería telo en conta.
Noutras palabras, os validadores de contratos intelixentes deben ter acceso a todos os datos nos que opera o contrato intelixente. Por exemplo, debería utilizarse unha única base de datos para contabilizar simultaneamente as moedas dixitais, os saldos dos usuarios, as transaccións dos usuarios e as marcas de tempo. Entón, nun contrato intelixente, a condición pode ser o saldo do usuario nunha determinada moeda, a chegada dun determinado momento ou o feito de que se realizou unha determinada transacción, pero nada máis.
Definición de contrato intelixente
En xeral, a terminoloxía en si foi acuñada polo investigador Nick Szabo e utilizada por primeira vez en 1994, e foi documentada en 1997 nun artigo que describe a idea mesma dos contratos intelixentes.
Os contratos intelixentes implican que se realiza algunha automatización da distribución de valor, que só pode depender daquelas condicións que estean predeterminadas de antemán. Na súa forma máis sinxela, parece un contrato con termos estritamente definidos, que está asinado por determinadas partes.
Os contratos intelixentes están deseñados para minimizar a confianza en terceiros. Ás veces queda totalmente excluído o centro de decisión do que todo depende. Ademais, tales contratos son máis fáciles de auditar. Esta é unha consecuencia dalgunhas características de deseño deste sistema, pero a maioría das veces entendemos por contrato intelixente un ambiente descentralizado e a presenza de funcións que permiten a calquera analizar a base de datos e realizar unha auditoría completa da execución dos contratos. Isto garante a protección contra os cambios retroactivos de datos que suporían cambios na execución do propio contrato. A dixitalización da maioría dos procesos ao crear e lanzar un contrato intelixente adoita simplificar a tecnoloxía e o custo da súa implementación.
Un exemplo sinxelo: servizo de fideicomiso
Vexamos un exemplo moi sinxelo. Axudarache a comprender a funcionalidade dos contratos intelixentes, así como a comprender mellor en que casos deberían utilizarse.
Tamén se pode implementar usando Bitcoin, aínda que agora mesmo Bitcoin aínda dificilmente se pode chamar unha plataforma completa para contratos intelixentes. Entón, temos algún comprador e temos unha tenda en liña. Un cliente quere mercar un monitor nesta tenda. No caso máis sinxelo, o comprador completa e envía un pago, e a tenda en liña acéptao, confírmao e despois envía a mercadoría. Non obstante, nesta situación é necesario unha gran confianza: o comprador debe confiar na tenda en liña para todo o custo do monitor. Dado que unha tenda en liña pode ter unha baixa reputación aos ollos do comprador, existe o risco de que, por algún motivo, despois de aceptar o pago, a tenda rexeite o servizo e non envíe os bens ao comprador. Polo tanto, o comprador fai a pregunta (e, en consecuencia, a tenda en liña fai esta pregunta) que se pode aplicar neste caso para minimizar tales riscos e facer que tales transaccións sexan máis fiables.
No caso de Bitcoin, é posible permitir que o comprador e o vendedor seleccionen de forma independente un mediador. Hai moitas persoas que están implicadas na resolución de cuestións controvertidas. E os nosos participantes poden escoller entre unha lista xeral de mediadores no que confiarán. Xuntos crean un enderezo multisinatura 2 de 3 onde hai tres claves e son necesarias dúas sinaturas con dúas claves calquera para gastar moedas dese enderezo. Unha chave pertencerá ao comprador, a segunda á tenda en liña e a terceira ao mediador. E a tal enderezo multisinatura o comprador enviará a cantidade necesaria para pagar o monitor. Agora, cando o vendedor ve que o diñeiro está bloqueado durante algún tempo nun enderezo multisinatura que depende del, pode enviar o monitor con seguridade por correo.
A continuación, o comprador recibe o paquete, inspecciona a mercadoría e toma unha decisión sobre a compra final. Pode estar completamente de acordo co servizo prestado e asinar a transacción coa súa chave, onde transfire moedas desde o enderezo multisinatura ao vendedor, ou pode estar insatisfeito con algo. No segundo caso, contacta cun mediador para elaborar unha transacción alternativa que distribuirá esas moedas de forma diferente.
Digamos que o monitor chegou un pouco raiado e que o kit non incluía un cable para conectarse ao ordenador, aínda que a web da tenda en liña dicía que o cable debería estar incluído no kit. A continuación, o comprador recolle as probas necesarias para demostrarlle ao mediador que foi enganado nesta situación: fai capturas de pantalla do sitio, fai unha foto do recibo do correo, fai unha foto dos arañazos no monitor e mostra que o selo estaba roto e o cable foi retirado. A tenda en liña, pola súa banda, recolle as súas probas e trasládasas ao mediador.
O mediador está interesado en satisfacer simultaneamente tanto a indignación do comprador como os intereses da tenda en liña (máis tarde quedará claro por que). Constitúe unha transacción na que as moedas dun enderezo multisinatura gastaranse en certa proporción entre o comprador, a tenda en liña e o mediador, xa que toma unha parte para si como recompensa polo seu traballo. Digamos que o 90% do importe total vai para o vendedor, o 5% para o mediador e o 5% de compensación para o comprador. O mediador asina esta transacción coa súa clave, pero aínda non se pode aplicar, porque require dúas sinaturas, pero só vale unha. Envía tal transacción tanto ao comprador como ao vendedor. Se polo menos un deles está satisfeito con esta opción de redistribución de moedas, a transacción asinarase previamente e distribuirase á rede. Para validalo, abonda con que unha das partes da transacción estea de acordo coa opción do mediador.
É importante escoller inicialmente un mediador para que ambos os participantes confíen nel. Neste caso, actuará con independencia dos intereses dun ou doutro e valorará obxectivamente a situación. Se o mediador non ofrece unha opción de distribución de moedas que satisfaga polo menos un participante, entón, unha vez acordado, tanto o comprador como a tenda en liña poden enviar as moedas a un novo enderezo multisinatura poñendo as súas dúas sinaturas. O novo enderezo multisinatura compilarase cun mediador diferente, que poderá ser máis competente na materia e ofrecer unha mellor opción.
Exemplo cun dormitorio e unha neveira
Vexamos un exemplo máis complexo que mostra as capacidades dun contrato intelixente de forma máis explícita.
Digamos que hai tres mozos que se mudaron recentemente ao mesmo dormitorio. Os tres están interesados en mercar unha neveira para a súa habitación que poidan usar xuntos. Un deles ofreceuse para recoller a cantidade necesaria para mercar unha neveira e negociar co vendedor. Non obstante, só se coñeceron recentemente e non hai suficiente confianza entre eles. Obviamente, dous deles están arriscando dándolle cartos ao terceiro. Ademais, deben chegar a un acordo na elección dun vendedor.
Poden utilizar o servizo de garantía, é dicir, elixir un mediador que supervisará a execución da transacción e resolverá cuestións controvertidas se xurden. Despois, unha vez acordado, elaboran un contrato intelixente e nel prescriben determinadas condicións.
A primeira condición é que antes dun tempo determinado, digamos dentro dunha semana, a conta de contrato intelixente correspondente debe recibir tres pagos desde determinados enderezos por un importe determinado. Se isto non ocorre, o contrato intelixente deixa de executarse e devolve as moedas a todos os participantes. Se se cumpre a condición, establécense os valores dos identificadores do vendedor e do mediador e compróbase a condición de que todos os participantes estean de acordo coa elección do vendedor e do mediador. Cando se cumpran todas as condicións, os fondos transferiranse aos enderezos especificados. Este enfoque pode protexer aos participantes da fraude de calquera lado e, en xeral, elimina a necesidade de confiar.
Vemos neste exemplo o propio principio de que esta capacidade de establecer paso a paso os parámetros para cumprir cada condición permítelle crear sistemas de calquera complexidade e profundidade de niveis aniñados. Ademais, primeiro pode definir a primeira condición no contrato intelixente e só despois do seu cumprimento pode establecer parámetros para a seguinte condición. Noutras palabras, a condición está formalmente escrita e os parámetros para ela xa se poden establecer durante o seu funcionamento.
Clasificación dos contratos intelixentes
Para a clasificación, pode establecer diferentes grupos de criterios. Non obstante, no momento do desenvolvemento tecnolóxico, catro deles son relevantes.
Os contratos intelixentes pódense distinguir polo seu contorno de execución, que pode ser centralizado ou descentralizado. No caso da descentralización, temos moita maior independencia e tolerancia a fallos á hora de executar contratos intelixentes.
Tamén se poden distinguir polo proceso de fixación e cumprimento de condicións: poden ser libremente programables, limitados ou predefinidos, é dicir, estritamente tipificados. Cando só hai 4 contratos intelixentes específicos na plataforma de contratos intelixentes, os parámetros dos mesmos pódense establecer de calquera forma. En consecuencia, configuralos é moito máis sinxelo: seleccionamos un contrato da lista e pasamos os parámetros.
Segundo o método de inicio, existen contratos intelixentes automatizados, é dicir, cando se dan determinadas condicións, son autoexecutables, e hai contratos nos que se especifican as condicións, pero a plataforma non verifica automaticamente o seu cumprimento; para iso deben iniciarse por separado.
Ademais, os contratos intelixentes varían no seu nivel de privacidade. Poden ser completamente abertos, parcial ou totalmente confidenciais. Isto último significa que os observadores de terceiros non ven os termos dos contratos intelixentes. Non obstante, o tema da privacidade é moi amplo e é mellor consideralo por separado do artigo actual.
A continuación, analizaremos os tres primeiros criterios para achegar máis claridade á comprensión do tema actual.
Contratos intelixentes por tempo de execución
En función do entorno de execución, distínguese entre plataformas de contrato intelixente centralizada e descentralizada. No caso dos contratos dixitais centralizados, utilízase un único servizo, onde só existe un validador e pode haber un servizo de copia de seguridade e recuperación, que tamén se xestiona de forma centralizada. Hai unha base de datos que almacena toda a información necesaria para establecer os termos do contrato intelixente e distribuír o valor que se ten en conta nesta mesma base de datos de servizos. Un servizo tan centralizado ten un cliente que establece condicións con determinadas solicitudes e utiliza tales contratos. Debido á natureza centralizada da plataforma, os mecanismos de autenticación poden ser menos seguros que nas criptomoedas.
Como exemplo, podemos tomar provedores de comunicacións móbiles (diferentes operadores móbiles). Digamos que un determinado operador mantén un rexistro centralizado do tráfico nos seus servidores, que se pode transmitir en diferentes formatos, por exemplo: en forma de chamadas de voz, transmisión de SMS, tráfico de Internet móbil, e segundo diferentes estándares, e tamén mantén rexistros. de fondos sobre saldos dos usuarios. En consecuencia, o provedor de comunicacións móbiles pode elaborar contratos de contabilización dos servizos prestados e do seu pagamento con diferentes condicións. Neste caso, é fácil establecer condicións como "enviar unha SMS con tal ou tal código a tal ou cal número e recibirás tales ou tales condicións para a distribución do tráfico".
Pódese poñer un exemplo máis: os bancos tradicionais con funcionalidade ampliada de banca por Internet e contratos moi sinxelos como pagos regulares, conversión automática de pagamentos recibidos, dedución automática de intereses nunha conta determinada, etc.
Se estamos a falar de contratos intelixentes cun contorno de execución descentralizado, entón temos un grupo de validadores. O ideal é que calquera persoa poida converterse en validador. Debido ao protocolo de sincronización da base de datos e ao chegar a un consenso, temos algunha base de datos común que agora almacenará todas as transaccións con contratos estritamente descritos, e non algunhas consultas condicionais, cuxos formatos adoitan cambiar e non hai unha especificación aberta. Aquí, as transaccións conterán instrucións para executar o contrato segundo unha especificación estrita. Esta especificación está aberta e, polo tanto, os propios usuarios da plataforma poden auditar e validar contratos intelixentes. Aquí vemos que as plataformas descentralizadas son superiores ás centralizadas en termos de independencia e tolerancia a fallos, pero o seu deseño e mantemento son moito máis complexos.
Contratos intelixentes polo método de fixación e cumprimento de condicións
Agora vexamos máis de cerca como poden diferir os contratos intelixentes na forma en que establecen e cumpren as condicións. Aquí centramos a nosa atención nos contratos intelixentes que son programables aleatoriamente e Turing completo. Un contrato intelixente completo de Turing permítelle establecer case todos os algoritmos como condicións para a execución do contrato: ciclos de escritura, algunhas funcións para calcular probabilidades e similares, ata os seus propios algoritmos de sinatura electrónica. Neste caso, queremos dicir unha escritura de lóxica verdadeiramente arbitraria.
Tamén hai contratos intelixentes arbitrarios, pero non os completos de Turing. Isto inclúe Bitcoin e Litecoin co seu propio script. Isto significa que só pode usar determinadas operacións en calquera orde, pero xa non pode escribir bucles nin os seus propios algoritmos.
Ademais, existen plataformas de contratos intelixentes que implementan contratos intelixentes predefinidos. Estes inclúen Bitshares e Steemit. Bitshares ten unha serie de contratos intelixentes para a negociación, a xestión de contas, a xestión da propia plataforma e os seus parámetros. Steemit é unha plataforma similar, pero xa non se centra na emisión de tokens e na negociación, como Bitshares, senón en blogs, é dicir, almacena e procesa contido de forma descentralizada.
Os contratos arbitrarios de Turing completos inclúen a plataforma Ethereum e RootStock, que aínda está en desenvolvemento. Polo tanto, a continuación deterémonos un pouco máis en detalle na plataforma de contrato intelixente Ethereum.
Contratos intelixentes por método de iniciación
Segundo o método de inicio, os contratos intelixentes tamén se poden dividir en polo menos dous grupos: automatizados e manuais (non automatizados). Os automatizados caracterízanse polo feito de que, dados todos os parámetros e condicións coñecidos, o contrato intelixente execútase completamente automaticamente, é dicir, non require enviar transaccións adicionais e gastar unha comisión adicional en cada execución posterior. A propia plataforma ten todos os datos para calcular como se completará o contrato intelixente. A lóxica alí non é arbitraria, senón predeterminada e todo isto é previsible. É dicir, pode estimar con antelación a complexidade de executar un contrato intelixente, utilizar algún tipo de comisión constante para iso e todos os procesos para a súa implementación son máis eficientes.
Para contratos intelixentes que se programan libremente, a execución non está automatizada. Para iniciar un contrato intelixente deste tipo, practicamente en cada paso cómpre crear unha nova transacción, que chamará á seguinte fase de execución ou ao seguinte método de contrato intelixente, pagar a comisión correspondente e esperar a que se confirme a transacción. A execución pode completarse con éxito ou non, porque o código do contrato intelixente é arbitrario e poden aparecer algúns momentos imprevisibles, como un bucle eterno, a falta dalgúns parámetros e argumentos, excepcións non controladas, etc.
Contas Ethereum
Tipos de contas de Ethereum
Vexamos que tipos de contas pode haber na plataforma Ethereum. Aquí só hai dous tipos de contas e non hai outras opcións. O primeiro tipo chámase conta de usuario, o segundo é unha conta de contrato. Imos descubrir en que se diferencian.
A conta de usuario só controla a clave persoal da sinatura electrónica. O propietario da conta xera o seu propio par de claves para a sinatura electrónica mediante o algoritmo ECDSA (Algoritmo de sinatura dixital de curva elíptica). Só as transaccións asinadas con esta chave poden cambiar o estado desta conta.
Ofrécese unha lóxica separada para a conta de contrato intelixente. Só se pode controlar mediante un código de software predefinido que determina completamente o comportamento do contrato intelixente: como xestionará as súas moedas en determinadas circunstancias, a iniciativa de que usuario e en que condicións adicionais se distribuirán estas moedas. Se os desenvolvedores non fornecen algúns puntos no código do programa, poden xurdir problemas. Por exemplo, un contrato intelixente pode recibir un determinado estado no que non acepta o inicio dunha execución posterior por parte de ningún dos usuarios. Neste caso, as moedas serán realmente conxeladas, porque o contrato intelixente non prevé saír deste estado.
Como se crean as contas en Ethereum
No caso dunha conta de usuario, o propietario xera de forma independente un par de claves mediante ECDSA. É importante ter en conta que Ethereum usa exactamente o mesmo algoritmo e exactamente a mesma curva elíptica para sinaturas electrónicas que Bitcoin, pero o enderezo calcúlase dun xeito lixeiramente diferente. Aquí, o resultado do hash dobre xa non se usa, como en Bitcoin, pero o hash único proporcionase coa función Keccak cunha lonxitude de 256 bits. Os bits menos significativos son cortados do valor resultante, é dicir, os 160 bits menos significativos do valor hash de saída. Como resultado, obtemos un enderezo en Ethereum. De feito, ocupa 20 bytes.
Teña en conta que o identificador da conta en Ethereum está codificado en hexadecimal sen aplicar unha suma de verificación, a diferenza de Bitcoin e moitos outros sistemas, onde o enderezo está codificado nun sistema numérico base 58 coa adición dunha suma de verificación. Isto significa que debes ter coidado ao traballar cos identificadores de contas en Ethereum: ata un erro no identificador está garantido que provocará a perda de moedas.
Hai unha característica importante e é que se crea unha conta de usuario a nivel xeral de base de datos no momento en que acepta o primeiro pago recibido.
A creación dunha conta de contrato intelixente leva un enfoque completamente diferente. Inicialmente, un dos usuarios escribe o código fonte do contrato intelixente, despois de que o código pasa por un compilador especial para a plataforma Ethereum, obtendo o bytecode para a súa propia máquina virtual Ethereum. O bytecode resultante colócase nun campo especial da transacción. Está certificado en nome da conta do iniciador. A continuación, esta transacción propágase por toda a rede e coloca o código do contrato intelixente. A comisión pola transacción e, en consecuencia, pola execución do contrato retírase do saldo da conta do iniciador.
Cada contrato intelixente contén necesariamente o seu propio construtor (deste contrato). Pode estar baleiro ou pode ter contido. Despois de executar o construtor, créase un identificador de conta de contrato intelixente, mediante o cal pode enviar moedas, chamar a determinados métodos de contrato intelixente, etc.
Estrutura da transacción de Ethereum
Para que quede máis claro, comezaremos a analizar a estrutura dunha transacción de Ethereum e un exemplo de código de contrato intelixente.
Unha transacción de Ethereum consta de varios campos. O primeiro deles, nonce, é un determinado número de serie da transacción relativo á propia conta que a distribúe e é o seu autor. Isto é necesario para distinguir transaccións dobres, é dicir, excluír o caso de aceptar dúas veces a mesma transacción. Ao usar un identificador, cada transacción ten un valor hash único.
A continuación vén un campo como prezo do gas. Isto indica o prezo ao que a moeda base de Ethereum se converte en gas, que se usa para pagar a execución do contrato intelixente e a asignación do recurso da máquina virtual. Qué significa?
En Bitcoin, as taxas son pagadas directamente pola moeda base: o propio Bitcoin. Isto é posible grazas a un mecanismo sinxelo para calculalos: pagamos estrictamente pola cantidade de datos que contén a transacción. En Ethereum a situación é máis complicada, porque é moi difícil confiar no volume de datos da transacción. Aquí, a transacción tamén pode conter código de programa que se executará na máquina virtual e cada operación da máquina virtual pode ter unha complexidade diferente. Tamén hai operacións que asignan memoria para variables. Terán unha complexidade propia, da que dependerá o pagamento de cada operación.
O custo de cada operación en gas equivalente será constante. Introdúcese especificamente co fin de determinar o custo constante de cada operación. Dependendo da carga da rede, o prezo do gas cambiará, é dicir, o coeficiente segundo o cal a moeda base se converterá nesta unidade auxiliar para pagar a comisión.
Hai unha característica máis dunha transacción en Ethereum: o bytecode que contén para a súa execución nunha máquina virtual executarase ata que se complete con algún resultado (éxito ou fracaso) ou ata que se esgote unha determinada cantidade de moedas asignadas para pagar a comisión. . É para evitar unha situación na que, en caso de erro, todas as moedas da conta do remitente foron gastadas en comisión (por exemplo, algún tipo de ciclo eterno iniciado nunha máquina virtual), existe o seguinte campo: iniciar gas (moitas veces chamado límite de gas): determina a cantidade máxima de moedas que o remitente está disposto a gastar para completar unha determinada transacción.
O seguinte campo chámase enderezo de destino. Isto inclúe o enderezo do destinatario das moedas ou o enderezo dun contrato intelixente específico cuxos métodos serán chamados. Despois chega o campo valor, onde se introduce a cantidade de moedas que se envían ao enderezo de destino.
A continuación é un campo interesante chamado datos, onde encaixa toda a estrutura. Este non é un campo separado, senón toda unha estrutura na que se define o código para a máquina virtual. Podes colocar datos arbitrarios aquí - hai regras separadas para iso.
E o último campo chámase sinatura. Contén simultaneamente tanto a sinatura electrónica do autor desta transacción como a clave pública coa que se verificará esta sinatura. Desde a chave pública pódese obter o identificador da conta do remitente desta transacción, é dicir, identificar de forma única a conta do remitente no propio sistema. Descubrimos o principal sobre a estrutura da transacción.
Exemplo de código de contrato intelixente para Solidity
Vexamos agora o contrato intelixente máis sinxelo usando un exemplo.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Arriba hai un código fonte simplificado que pode conter as moedas dos usuarios e devolvelas baixo demanda.
Así, existe un contrato intelixente do Banco que realiza as seguintes funcións: acumula moedas no seu saldo, é dicir, cando se confirma unha transacción e se coloca ese contrato intelixente, créase unha nova conta que pode conter moedas no seu saldo; lembra aos usuarios e á distribución de moedas entre eles; ten varios métodos para xestionar saldos, é dicir, é posible repoñer, retirar e comprobar o saldo do usuario.
Imos pasar por cada liña de código fonte. Este contrato ten campos constantes. Un deles, con enderezo tipo, chámase propietario. Aquí o contrato lembra o enderezo do usuario que creou este contrato intelixente. Ademais, hai unha estrutura dinámica que mantén a correspondencia entre os enderezos dos usuarios e os saldos.
Isto é seguido polo método Banco - ten o mesmo nome que o contrato. En consecuencia, este é o seu construtor. Aquí asígnaselle á variable propietario o enderezo da persoa que colocou este contrato intelixente na rede. Isto é o único que ocorre neste construtor. É dicir, o msg neste caso son exactamente os datos que foron transferidos á máquina virtual xunto coa transacción que contén o código completo deste contrato. En consecuencia, msg.sender é o autor desta transacción que aloxa este código. Será o propietario do contrato intelixente.
O método de depósito permítelle transferir un determinado número de moedas á conta do contrato por transacción. Neste caso, o contrato intelixente, ao recibir estas moedas, déixaas no seu balance, pero rexistra na estrutura de saldos quen foi exactamente o remitente destas moedas para saber a quen pertencen.
O seguinte método chámase retirar e leva un parámetro: a cantidade de moedas que alguén quere retirar deste banco. Isto comproba se hai moedas suficientes no saldo do usuario que chama a este método para envialas. Se hai suficientes, entón o contrato intelixente devolve ese número de moedas á persoa que chama.
A continuación vén o método para comprobar o saldo actual do usuario. Quen chame a este método empregarase para recuperar este saldo no contrato intelixente. Paga a pena notar que o modificador deste método é view. Isto significa que o propio método non cambia as variables da súa clase de ningún xeito e en realidade é só un método de lectura. Non se crea ningunha transacción separada para chamar a este método, non se paga ningunha taxa e todos os cálculos realízanse localmente, despois de que o usuario recibe o resultado.
O método de matar é necesario para destruír o estado do contrato intelixente. E aquí hai unha comprobación adicional de se o que chama este método é o propietario deste contrato. Se é así, entón o contrato autodestrúese e a función de destrución toma un parámetro: o identificador da conta ao que o contrato enviará todas as moedas que queden no seu saldo. Neste caso, as moedas restantes irán automaticamente ao enderezo do propietario do contrato.
Como funciona un nodo completo na rede Ethereum?
Vexamos esquemáticamente como se executan estes contratos intelixentes na plataforma Ethereum e como funciona un nodo de rede completo.
Un nodo completo na rede Ethereum debe ter polo menos catro módulos.
O primeiro, como para calquera protocolo descentralizado, é o módulo de rede P2P: un módulo para conexión de rede e traballo con outros nodos, onde se intercambian bloques, transaccións e información sobre outros nodos. Este é un compoñente tradicional para todas as criptomoedas descentralizadas.
A continuación, temos un módulo para almacenar datos da cadea de bloques, procesar, escoller unha rama prioritaria, engadir bloques, desvincular bloques, validar estes bloques, etc.
O terceiro módulo chámase EVM (máquina virtual de Ethereum): esta é unha máquina virtual que recibe o bytecode das transaccións de Ethereum. Este módulo toma o estado actual dunha conta particular e fai cambios no seu estado en función do bytecode recibido. A versión da máquina virtual en cada nodo da rede debe ser a mesma. Os cálculos que se realizan en cada nodo de Ethereum son exactamente os mesmos, pero ocorren de forma asíncrona: alguén verifica e acepta esta transacción antes, é dicir, executa todo o código contido nela, e alguén máis tarde. En consecuencia, cando se crea unha transacción, distribúese na rede, os nodos acéptana e, no momento da verificación, do mesmo xeito que se executa Bitcoin Script en Bitcoin, execútase aquí o bytecode da máquina virtual.
Unha transacción considérase verificada se se executou todo o código contido nela, se xerou e se gardou un novo estado dunha determinada conta ata que se aclare se se aplicou ou non esta transacción. Se se aplica a transacción, entón este estado considérase non só completado, senón tamén actual. Existe unha base de datos que almacena o estado de cada conta para cada nodo da rede. Debido ao feito de que todos os cálculos ocorren do mesmo xeito e o estado da cadea de bloques é o mesmo, a base de datos que contén os estados de todas as contas tamén será a mesma para cada nodo.
Mitos e limitacións dos contratos intelixentes
En canto ás restricións que existen para plataformas de contratos intelixentes similares a Ethereum, pódense citar as seguintes:
- execución de código;
- asignar memoria;
- datos da cadea de bloques;
- enviar pagamentos;
- crear un novo contrato;
- chamar a outros contratos.
Vexamos as restricións que se impoñen a unha máquina virtual e, en consecuencia, disipemos algúns mitos sobre os contratos intelixentes. Nunha máquina virtual, que pode estar non só en Ethereum, senón tamén en plataformas similares, pode realizar operacións lóxicas verdadeiramente arbitrarias, é dicir, escribir código e executarase alí, ademais pode asignar memoria. Non obstante, a taxa págase por separado por cada operación e por cada unidade adicional de memoria asignada.
A continuación, a máquina virtual pode ler datos da base de datos blockchain para usar estes datos como un disparador para executar unha ou outra lóxica de contrato intelixente. A máquina virtual pode crear e enviar transaccións, pode crear novos contratos e métodos de chamada doutros contratos intelixentes que xa están publicados na rede: existentes, dispoñibles, etc.
O mito máis común é que os contratos intelixentes de Ethereum poden usar información de calquera recurso de Internet nos seus termos. O certo é que unha máquina virtual non pode enviar unha solicitude de rede a algún recurso de información externo en Internet, é dicir, é imposible redactar un contrato intelixente que reparta valor entre os usuarios en función, por exemplo, do tempo que faga fóra, por exemplo. ou quen gañou algún campionato, ou en función de que outro incidente ocorreu no mundo exterior, porque a información sobre estes incidentes simplemente non está na base de datos da propia plataforma. É dicir, non hai nada na cadea de bloques sobre isto. Se non aparece alí, a máquina virtual non pode usar estes datos como disparadores.
Desvantaxes de Ethereum
Imos enumerar os principais. A primeira desvantaxe é que hai algunhas dificultades para deseñar, desenvolver e probar contratos intelixentes en Ethereum (Ethereum usa a linguaxe Solidity para escribir contratos intelixentes). De feito, a práctica demostra que unha porcentaxe moi grande de todos os erros pertencen ao factor humano. Isto é realmente certo para os contratos intelixentes de Ethereum xa escritos que teñen unha complexidade media ou superior. Se para contratos intelixentes simples a probabilidade dun erro é pequena, entón en contratos intelixentes complexos hai moitas veces erros que levan ao roubo de fondos, a súa conxelación, a destrución de contratos intelixentes de forma inesperada, etc. Moitos destes casos xa están presentes. coñecido.
A segunda desvantaxe é que a propia máquina virtual non é perfecta, xa que tamén está escrita por persoas. Pode executar comandos arbitrarios, e aí radica a vulnerabilidade: pódense configurar unha serie de comandos dun xeito determinado que levará a consecuencias non previstas de antemán. Esta é unha área moi complexa, pero xa hai varios estudos que demostran que estas vulnerabilidades existen na versión actual da rede Ethereum e que poden levar ao fracaso de moitos contratos intelixentes.
Outra gran dificultade, pódese considerar unha desvantaxe. Está no feito de que practica ou tecnicamente pode chegar á conclusión de que se compila o bytecode dun contrato que se executará nunha máquina virtual, pode determinar algunha orde específica de operacións. Cando se realizan en conxunto, estas operacións cargarán moito a máquina virtual e ralentizarán de forma desproporcionada a taxa que se pagou por realizar estas operacións.
No pasado, xa houbo un período no desenvolvemento de Ethereum, cando moitos rapaces que comprenderon en detalle o funcionamento dunha máquina virtual atoparon tales vulnerabilidades. De feito, as transaccións pagaban unha tarifa moi pequena, pero practicamente freaban toda a rede. Estes problemas son moi difíciles de resolver, xa que é necesario, en primeiro lugar, determinalos, en segundo lugar, axustar o prezo para realizar estas operacións e, en terceiro lugar, realizar un hard fork, o que supón actualizar todos os nodos da rede a unha nova versión. do software, e despois activación simultánea destes cambios.
En canto a Ethereum, realizouse moita investigación, adquiriuse moita experiencia práctica: tanto positiva como negativa, pero aínda quedan dificultades e vulnerabilidades que aínda hai que tratar dalgún xeito.
Entón, a parte temática do artigo está rematada, pasemos ás preguntas que xorden con bastante frecuencia.
Preguntas máis frecuentes
— Se todas as partes dun contrato intelixente existente queren cambiar os termos, poden cancelar este contrato intelixente mediante multisig e, a continuación, crear un novo contrato intelixente con condicións actualizadas da súa execución?
A resposta aquí será dobre. Por que? Porque por unha banda, un contrato intelixente defínese unha vez e xa non implica ningún cambio e, por outra banda, pode ter unha lóxica pre-escrita que prevé un cambio total ou parcial dalgunhas condicións. É dicir, se queres cambiar algo no teu contrato intelixente, debes prescribir as condicións nas que podes actualizar estas condicións. En consecuencia, só de forma tan prudente poderá organizarse a renovación do contrato. Pero aquí tamén podes ter problemas: cometer algún erro e obter unha vulnerabilidade correspondente. Polo tanto, tales cousas deben ser moi detalladas e coidadosamente deseñadas e probadas.
— E se o mediador asina un acordo cunha das partes participantes: escrow ou smart contract? Requírese un mediador nun contrato intelixente?
Non se require un mediador nun contrato intelixente. Pode que non exista. Se no caso do depósito en garantía, o mediador entra nunha conspiración cunha das partes, entón si, este esquema perde bruscamente todo o seu valor. Polo tanto, os mediadores son seleccionados de forma que todas as partes implicadas neste proceso confían neles ao mesmo tempo. En consecuencia, simplemente non transferirá moedas a un enderezo multisinatura cun mediador no que non confíe.
— É posible cunha transacción de Ethereum transferir moitos tokens diferentes desde o teu enderezo a diferentes enderezos de destino, por exemplo, enderezos de intercambio onde se negocian estes tokens?
Esta é unha boa pregunta e refírese ao modelo de transacción de Ethereum e en que se diferencia do modelo de Bitcoin. E a diferenza é radical. Se no modelo de transacción de Ethereum simplemente transfire moedas, entón só se transfiren dun enderezo a outro, sen cambios, só a cantidade específica que especificaches. Noutras palabras, non se trata dun modelo de saídas non gastadas (UTXO), senón dun modelo de contas e saldos correspondentes. Teoricamente, é posible enviar varios tokens diferentes nunha transacción á vez se escribes un contrato intelixente astuto, pero aínda terás que facer moitas transaccións, crear un contrato, transferirlle fichas e moedas e chamar ao método adecuado. . Isto require esforzo e tempo, polo que na práctica non funciona así e todos os pagos en Ethereum realízanse en transaccións separadas.
— Un dos mitos sobre a plataforma Ethereum é que é imposible describir condicións que dependerán dos datos dun recurso externo de Internet, entón que facer?
A solución é que o contrato intelixente en si pode proporcionar un ou varios oráculos de confianza, que recollen datos sobre o estado das cousas no mundo exterior e os transmiten aos contratos intelixentes a través de métodos especiais. O propio contrato considera verdadeiros os datos que recibiu de partes de confianza. Para unha maior fiabilidade, simplemente escolla un gran grupo de oráculos e minimice o risco da súa connivencia. O propio contrato pode non ter en conta datos de oráculos que contradigan a maioría.
Unha das conferencias do curso en liña sobre Blockchain está dedicada a este tema - “".
Fonte: www.habr.com