En aquest article, veurem què són els contractes intel·ligents, què són, coneixerem diferents plataformes de contractes intel·ligents, les seves característiques i també parlarem de com funcionen i quins avantatges poden aportar. Aquest material serà molt útil per als lectors que no coneguin bé el tema dels contractes intel·ligents, però vulguin apropar-se a entendre-lo.
Contracte regular vs. contracte intel·ligent
Abans d'aprofundir en els detalls, prenguem un exemple de les diferències entre un contracte normal, que s'especifica en paper, i un contracte intel·ligent, que es representa digitalment.
Com funcionava això abans de l'arribada dels contractes intel·ligents? Imagineu un grup de persones que volen establir unes regles i condicions per a la distribució de valors, així com un mecanisme determinat per garantir la implementació d'aquesta distribució d'acord amb les regles i condicions donades. Després es reunien, elaboraven un paper on anotaven les seves dades identificatives, els termes, els valors implicats, els dataven i els signaven. Aquest contracte també va ser certificat per una persona de confiança, com un notari. A més, aquestes persones van anar en diferents direccions amb la seva còpia en paper d'aquest contracte i van començar a realitzar algunes accions que potser no corresponien al mateix contracte, és a dir, van fer una cosa, però en paper es va certificar que havien de fer alguna cosa. completament diferent. I com sortir d'aquesta situació? De fet, un dels membres del grup ha d'agafar aquest paper, prendre algunes proves, portar-lo als tribunals i aconseguir el compliment entre el contracte i les accions reals. Molt sovint, és difícil aconseguir una implementació justa d'aquest contracte, la qual cosa comporta conseqüències desagradables.
Què es pot dir dels contractes intel·ligents? Combinen tant la possibilitat de redactar els termes del contracte com el mecanisme per a la seva estricta implementació. Si s'han fixat les condicions i s'ha signat la corresponent transacció o sol·licitud, aleshores, un cop acceptada aquesta sol·licitud o transacció, ja no és possible modificar les condicions ni afectar-ne la realització.
Hi ha un validador o una xarxa sencera, així com una base de dades que emmagatzema tots els contractes intel·ligents que es van presentar per a l'execució en estricte ordre cronològic. També és important que aquesta base de dades contingui totes les condicions d'activació per executar el contracte intel·ligent. A més, ha de tenir en compte el mateix valor la distribució del qual es descriu en el contracte. Si això s'aplica a alguna moneda digital, aquesta base de dades hauria de tenir-ho en compte.
En altres paraules, els validadors de contractes intel·ligents han de tenir accés a totes les dades amb les quals opera el contracte intel·ligent. Per exemple, s'hauria d'utilitzar una base de dades única per tenir en compte simultàniament les monedes digitals, els saldos dels usuaris, les transaccions dels usuaris i les marques de temps. Aleshores, en un contracte intel·ligent, la condició pot ser el saldo de l'usuari en una determinada moneda, l'arribada d'un temps determinat o el fet que s'hagi realitzat una determinada transacció, però res més.
Definició de contracte intel·ligent
En general, la terminologia mateixa va ser encunyada per l'investigador Nick Szabo i utilitzada per primera vegada el 1994, i es va documentar el 1997 en un article que descriu la idea mateixa dels contractes intel·ligents.
Els contractes intel·ligents impliquen que es realitza una certa automatització de la distribució del valor, que només pot dependre d'aquelles condicions que estiguin predeterminades per endavant. En la seva forma més senzilla, sembla un contracte amb termes estrictament definits, que és signat per determinades parts.
Els contractes intel·ligents estan dissenyats per minimitzar la confiança en tercers. De vegades queda totalment exclòs el centre de decisió del qual tot depèn. A més, aquests contractes són més fàcils d'auditar. Això és conseqüència d'algunes característiques de disseny d'aquest sistema, però sovint entenem per contracte intel·ligent un entorn descentralitzat i la presència de funcions que permeten a qualsevol analitzar la base de dades i realitzar una auditoria completa de l'execució dels contractes. D'aquesta manera es garanteix la protecció contra els canvis de dades retroactius que comportarien canvis en l'execució del mateix contracte. La digitalització de la majoria de processos en crear i llançar un contracte intel·ligent sovint simplifica la tecnologia i el cost de la seva implementació.
Un exemple senzill: servei de fideïcomís
Vegem un exemple molt senzill. Us ajudarà a acostar-vos a entendre la funcionalitat dels contractes intel·ligents, així com a entendre millor en quins casos s'han d'utilitzar.
També es pot implementar mitjançant Bitcoin, encara que ara mateix Bitcoin encara difícilment es pot anomenar una plataforma completa per a contractes intel·ligents. Així doncs, tenim algun comprador i tenim una botiga en línia. Un client vol comprar un monitor d'aquesta botiga. En el cas més senzill, el comprador completa i envia un pagament, i la botiga en línia l'accepta, el confirma i després envia la mercaderia. Tanmateix, en aquesta situació cal una gran confiança: el comprador ha de confiar en la botiga en línia per a tot el cost del monitor. Com que una botiga en línia pot tenir una reputació baixa als ulls del comprador, hi ha el risc que per algun motiu, després d'acceptar el pagament, la botiga rebutgi el servei i no enviï la mercaderia al comprador. Per tant, el comprador fa la pregunta (i, en conseqüència, la botiga en línia fa aquesta pregunta) què es pot aplicar en aquest cas per minimitzar aquests riscos i fer que aquestes transaccions siguin més fiables.
En el cas de Bitcoin, és possible permetre que el comprador i el venedor seleccionen un mediador de manera independent. Hi ha moltes persones que estan involucrades en la resolució de qüestions polèmiques. I els nostres participants poden triar d'una llista general de mediadors en qui confiaran. Junts creen una adreça multisignatura 2 de 3 on hi ha tres claus i es requereixen dues signatures amb dues claus qualsevol per gastar monedes d'aquesta adreça. Una clau serà del comprador, la segona de la botiga en línia i la tercera del mediador. I a aquesta adreça multisigna, el comprador enviarà l'import necessari per pagar el monitor. Ara, quan el venedor veu que els diners estan bloquejats durant un temps en una adreça de multisignatura que depèn d'ell, pot enviar el monitor amb seguretat per correu.
A continuació, el comprador rep el paquet, inspecciona la mercaderia i pren una decisió sobre la compra final. Pot estar totalment d'acord amb el servei prestat i signar la transacció amb la seva clau, on transfereix monedes des de l'adreça multisignatura al venedor, o pot estar insatisfet amb alguna cosa. En el segon cas, es posa en contacte amb un mediador per elaborar una transacció alternativa que distribuirà aquestes monedes de manera diferent.
Suposem que el monitor va arribar una mica ratllat i que el kit no incloïa un cable per connectar-se a l'ordinador, tot i que el web de la botiga en línia deia que el cable s'havia d'incloure al kit. A continuació, el comprador recull les proves necessàries per demostrar al mediador que va ser enganyat en aquesta situació: fa captures de pantalla del lloc, fa una foto del rebut del correu, fa una foto de les ratllades al monitor i mostra que el segell estava trencat i el cable es va treure. La botiga en línia, al seu torn, recull les seves proves i les trasllada al mediador.
El mediador està interessat a satisfer alhora la indignació del comprador i els interessos de la botiga en línia (més endavant es veurà clar per què). Es tracta d'una transacció en la qual les monedes d'una adreça multisigna es gastaran en certa proporció entre el comprador, la botiga en línia i el mediador, ja que aquest s'emporta una part com a recompensa per la seva feina. Suposem que el 90% de l'import total va al venedor, el 5% al mediador i el 5% a la compensació al comprador. El mediador signa aquesta transacció amb la seva clau, però encara no es pot aplicar, perquè requereix dues firmes, però només una val la pena. Envia aquesta transacció tant al comprador com al venedor. Si almenys un d'ells està satisfet amb aquesta opció de redistribució de monedes, la transacció es presignarà i es distribuirà a la xarxa. Per validar-ho, n'hi ha prou que una de les parts de l'operació estigui d'acord amb l'opció del mediador.
És important triar inicialment un mediador perquè els dos participants confiïn en ell. En aquest cas, actuarà amb independència dels interessos d'un o altre i valorarà objectivament la situació. Si el mediador no ofereix una opció de distribució de monedes que satisfi almenys un participant, aleshores, després d'haver-ho acordat, tant el comprador com la botiga en línia poden enviar les monedes a una nova adreça multisignatura posant les seves dues signatures. La nova adreça multisigna es compilarà amb un mediador diferent, que pot ser més competent en la matèria i oferir una millor opció.
Exemple amb un dormitori i una nevera
Vegem un exemple més complex que mostra les capacitats d'un contracte intel·ligent de manera més explícita.
Suposem que hi ha tres nois que recentment es van mudar a la mateixa habitació. Els tres estan interessats a comprar una nevera per a la seva habitació que puguin utilitzar junts. Un d'ells es va oferir voluntari per recollir la quantitat necessària per comprar una nevera i negociar amb el venedor. Tanmateix, fa poc que es van conèixer i no hi ha prou confiança entre ells. Evidentment, dos d'ells arrisquen donant diners al tercer. A més, han d'arribar a un acord per triar un venedor.
Poden utilitzar el servei de garantia, és a dir, triar un mediador que supervisarà l'execució de la transacció i resoldrà els problemes controvertits si n'hi hagués. Després, després d'haver-hi acordat, elaboren un contracte intel·ligent i hi prescriuen determinades condicions.
La primera condició és que abans d'un temps determinat, per exemple, dins d'una setmana, el compte de contracte intel·ligent corresponent hagi de rebre tres pagaments des de determinades adreces per un import determinat. Si això no passa, el contracte intel·ligent deixa d'executar-se i retorna les monedes a tots els participants. Si es compleix la condició, s'estableixen els valors dels identificadors del venedor i del mediador i es verifica la condició que tots els participants estiguin d'acord amb l'elecció del venedor i del mediador. Quan es compleixin totes les condicions, els fons es transferiran a les adreces especificades. Aquest enfocament pot protegir els participants del frau des de qualsevol banda i, en general, elimina la necessitat de confiar.
Veiem en aquest exemple el principi mateix que aquesta capacitat d'establir pas a pas els paràmetres per complir cada condició us permet crear sistemes de qualsevol complexitat i profunditat de nivells imbricats. A més, primer podeu definir la primera condició al contracte intel·ligent i només després del seu compliment podeu establir paràmetres per a la següent condició. En altres paraules, la condició s'escriu formalment i els paràmetres ja es poden establir durant el seu funcionament.
Classificació dels contractes intel·ligents
Per a la classificació, podeu establir diferents grups de criteris. Tanmateix, en el moment del desenvolupament tecnològic, quatre d'ells són rellevants.
Els contractes intel·ligents es poden distingir pel seu entorn d'execució, que pot ser centralitzat o descentralitzat. En el cas de la descentralització, tenim molta més independència i tolerància a fallades a l'hora d'executar contractes intel·ligents.
També es poden distingir pel procés d'establiment i compliment de condicions: poden ser lliurement programables, limitats o predefinits, és a dir, estrictament mecanografiats. Quan només hi ha 4 contractes intel·ligents específics a la plataforma de contractes intel·ligents, els paràmetres es poden configurar de qualsevol manera. En conseqüència, configurar-los és molt més senzill: seleccionem un contracte de la llista i passem els paràmetres.
Segons el mètode d'inici, hi ha contractes intel·ligents automatitzats, és a dir, quan es donen determinades condicions, s'executen per si mateix, i hi ha contractes en què s'especifiquen les condicions, però la plataforma no en verifica automàticament el compliment; per això s'han d'iniciar per separat.
A més, els contractes intel·ligents varien en el seu nivell de privadesa. Poden ser totalment oberts, parcialment o totalment confidencials. Això últim significa que els observadors de tercers no veuen els termes dels contractes intel·ligents. Tanmateix, el tema de la privadesa és molt ampli i és millor considerar-lo per separat de l'article actual.
A continuació analitzarem amb més detall els tres primers criteris per aportar més claredat a la comprensió del tema actual.
Contractes intel·ligents per temps d'execució
En funció de l'entorn d'execució, es fa una distinció entre plataformes de contracte intel·ligent centralitzades i descentralitzades. En el cas dels contractes digitals centralitzats, s'utilitza un únic servei, on només hi ha un validador i hi pot haver un servei de còpia de seguretat i recuperació, que també es gestiona de manera centralitzada. Hi ha una base de dades que emmagatzema tota la informació necessària per establir els termes del contracte intel·ligent i distribuir el valor que es té en compte en aquesta mateixa base de dades de serveis. Aquest servei centralitzat té un client que estableix condicions amb determinades peticions i utilitza aquests contractes. A causa de la naturalesa centralitzada de la plataforma, els mecanismes d'autenticació poden ser menys segurs que en les criptomonedes.
Com a exemple, podem prendre els proveïdors de comunicacions mòbils (diferents operadors mòbils). Suposem que un determinat operador manté un registre centralitzat del trànsit als seus servidors, que es pot transmetre en diferents formats, per exemple: en forma de trucades de veu, transmissió d'SMS, trànsit d'Internet mòbil, i segons diferents estàndards, i també conserva registres. de fons sobre els saldos dels usuaris. En conseqüència, el proveïdor de comunicacions mòbils pot formalitzar contractes de comptabilització dels serveis prestats i el seu pagament amb diferents condicions. En aquest cas, és fàcil establir condicions com "enviar un SMS amb tal o tal codi a tal o tal número i rebràs tal o tal condicions per a la distribució del trànsit".
Un exemple més es pot posar: els bancs tradicionals amb funcionalitats ampliades de banca per Internet i contractes molt senzills com ara pagaments regulars, conversió automàtica de pagaments entrants, deducció automàtica d'interessos a un compte determinat, etc.
Si estem parlant de contractes intel·ligents amb un entorn d'execució descentralitzat, tenim un grup de validadors. L'ideal és que qualsevol pugui convertir-se en validador. A causa del protocol de sincronització de bases de dades i d'arribar a un consens, tenim una base de dades comuna que ara emmagatzemarà totes les transaccions amb contractes estrictament descrits, i no algunes consultes condicionals, els formats de les quals sovint canvien i no hi ha cap especificació oberta. Aquí, les transaccions contindran instruccions per executar el contracte segons una especificació estricta. Aquesta especificació és oberta i, per tant, els mateixos usuaris de la plataforma poden auditar i validar contractes intel·ligents. Aquí veiem que les plataformes descentralitzades són superiors a les centralitzades pel que fa a independència i tolerància a errors, però el seu disseny i manteniment són molt més complexos.
Contractes intel·ligents pel mètode de fixació i compliment de condicions
Ara fem una ullada més de prop a com poden diferir els contractes intel·ligents en la manera com estableixen i compleixen les condicions. Aquí ens centrem en els contractes intel·ligents que són programables aleatòriament i Turing complet. Un contracte intel·ligent complet de Turing us permet establir gairebé tots els algorismes com a condicions per a l'execució del contracte: cicles d'escriptura, algunes funcions per calcular probabilitats i similars, fins als vostres propis algorismes de signatura electrònica. En aquest cas, ens referim a una escriptura de lògica realment arbitrària.
També hi ha contractes intel·ligents arbitraris, però no complets de Turing. Això inclou Bitcoin i Litecoin amb el seu propi script. Això vol dir que només podeu utilitzar determinades operacions en qualsevol ordre, però ja no podeu escriure bucles ni els vostres propis algorismes.
A més, hi ha plataformes de contracte intel·ligent que implementen contractes intel·ligents predefinits. Aquests inclouen Bitshares i Steemit. Bitshares disposa d'una sèrie de contractes intel·ligents per al comerç, la gestió de comptes, la gestió de la pròpia plataforma i els seus paràmetres. Steemit és una plataforma similar, però ja no es centra en l'emissió de fitxes i el comerç, com Bitshares, sinó en els blocs, és a dir, emmagatzema i processa contingut de manera descentralitzada.
Els contractes arbitraris de Turing complets inclouen la plataforma Ethereum i RootStock, que encara està en desenvolupament. Per tant, a continuació ens detenem una mica més en detall a la plataforma de contracte intel·ligent Ethereum.
Contractes intel·ligents per mètode d'iniciació
Segons el mètode d'inici, els contractes intel·ligents també es poden dividir en almenys dos grups: automatitzats i manuals (no automatitzats). Els automatitzats es caracteritzen pel fet que, tenint en compte tots els paràmetres i condicions coneguts, el contracte intel·ligent s'executa completament automàticament, és a dir, no requereix l'enviament de transaccions addicionals i la despesa d'una comissió addicional en cada execució posterior. La plataforma mateixa té totes les dades per calcular com es completarà el contracte intel·ligent. La lògica allà no és arbitrària, sinó predeterminada i tot això és previsible. És a dir, es pot estimar per endavant la complexitat d'executar un contracte intel·ligent, utilitzar-hi algun tipus de comissió constant i tots els processos per a la seva implementació són més eficients.
Per als contractes intel·ligents que es programen lliurement, l'execució no està automatitzada. Per iniciar aquest contracte intel·ligent, pràcticament a cada pas cal crear una nova transacció, que anomenarà la següent etapa d'execució o el següent mètode de contracte intel·ligent, pagar la comissió corresponent i esperar que es confirmi la transacció. L'execució pot finalitzar amb èxit o no, perquè el codi del contracte intel·ligent és arbitrari i poden aparèixer alguns moments impredictibles, com ara un bucle etern, la manca d'alguns paràmetres i arguments, excepcions no gestionades, etc.
Comptes d'Ethereum
Tipus de comptes d'Ethereum
Vegem quins tipus de comptes hi pot haver a la plataforma Ethereum. Aquí només hi ha dos tipus de comptes i no hi ha altres opcions. El primer tipus s'anomena compte d'usuari, el segon és un compte de contracte. Anem a esbrinar en què es diferencien.
El compte d'usuari només està controlat per la clau personal de la signatura electrònica. El propietari del compte genera el seu propi parell de claus per a la signatura electrònica mitjançant l'algoritme ECDSA (Algoritme de signatura digital de corba el·líptica). Només les transaccions signades amb aquesta clau poden canviar l'estat d'aquest compte.
Es proporciona una lògica independent per al compte de contracte intel·ligent. Només es pot controlar mitjançant un codi de programari predefinit que determina completament el comportament del contracte intel·ligent: com gestionarà les seves monedes en determinades circumstàncies, a iniciativa de quin usuari i en quines condicions addicionals es distribuiran aquestes monedes. Si els desenvolupadors no proporcionen alguns punts al codi del programa, poden sorgir problemes. Per exemple, un contracte intel·ligent pot rebre un estat determinat en què no accepta l'inici d'execucions posteriors per part de cap dels usuaris. En aquest cas, les monedes es congelaran, perquè el contracte intel·ligent no preveu sortir d'aquest estat.
Com es creen els comptes a Ethereum
En el cas d'un compte d'usuari, el propietari genera de manera independent un parell de claus mitjançant ECDSA. És important tenir en compte que Ethereum utilitza exactament el mateix algorisme i exactament la mateixa corba el·líptica per a signatures electròniques que Bitcoin, però l'adreça es calcula d'una manera lleugerament diferent. Aquí, el resultat del doble hashing ja no s'utilitza, com a Bitcoin, però el hash simple es proporciona amb la funció Keccak amb una longitud de 256 bits. Els bits menys significatius es tallen del valor resultant, és a dir, els 160 bits menys significatius del valor hash de sortida. Com a resultat, obtenim una adreça a Ethereum. De fet, ocupa 20 bytes.
Tingueu en compte que l'identificador del compte a Ethereum està codificat en hexadecimal sense aplicar una suma de verificació, a diferència de Bitcoin i molts altres sistemes, on l'adreça es codifica en un sistema de números de base 58 amb l'addició d'una suma de verificació. Això vol dir que cal anar amb compte quan es treballa amb els identificadors de compte a Ethereum: fins i tot un error en l'identificador pot provocar la pèrdua de monedes.
Hi ha una característica important i és que es crea un compte d'usuari a nivell de base de dades general en el moment en què accepta el primer pagament entrant.
La creació d'un compte de contracte intel·ligent té un enfocament completament diferent. Inicialment, un dels usuaris escriu el codi font del contracte intel·ligent, després del qual el codi es passa a través d'un compilador especial per a la plataforma Ethereum, obtenint bytecode per a la seva pròpia màquina virtual Ethereum. El bytecode resultant es col·loca en un camp especial de la transacció. Es certifica en nom del compte de l'iniciador. A continuació, aquesta transacció es propaga per tota la xarxa i col·loca el codi de contracte intel·ligent. La comissió per l'operació i, en conseqüència, per l'execució del contracte es retira del saldo del compte de l'iniciador.
Cada contracte intel·ligent conté necessàriament el seu propi constructor (d'aquest contracte). Pot estar buit o pot tenir contingut. Després d'executar el constructor, es crea un identificador de compte de contracte intel·ligent, amb el qual podeu enviar monedes, trucar a determinats mètodes de contracte intel·ligent, etc.
Estructura de transaccions d'Ethereum
Per fer-ho més clar, començarem a veure l'estructura d'una transacció d'Ethereum i un exemple de codi de contracte intel·ligent.
Una transacció d'Ethereum consta de diversos camps. El primer d'ells, nonce, és un número de sèrie determinat de la transacció relatiu al propi compte que la distribueix i n'és l'autor. Això és necessari per distingir les operacions dobles, és a dir, per excloure el cas en què la mateixa operació s'accepta dues vegades. En utilitzar un identificador, cada transacció té un valor hash únic.
A continuació ve un camp com preu del gas. Això indica el preu al qual la moneda base d'Ethereum es converteix en gas, que s'utilitza per pagar l'execució del contracte intel·ligent i l'assignació del recurs de la màquina virtual. Què vol dir?
A Bitcoin, les tarifes es paguen directament per la moneda base: el mateix Bitcoin. Això és possible gràcies a un mecanisme senzill per calcular-los: paguem estrictament per la quantitat de dades contingudes en la transacció. A Ethereum la situació és més complicada, perquè és molt difícil confiar en el volum de dades de transaccions. Aquí, la transacció també pot contenir codi de programa que s'executarà a la màquina virtual, i cada operació de la màquina virtual pot tenir una complexitat diferent. També hi ha operacions que assignen memòria per a variables. Tindran la seva pròpia complexitat, de la qual dependrà el pagament de cada operació.
El cost de cada operació en gas equivalent serà constant. S'introdueix específicament per tal de determinar el cost constant de cada operació. En funció de la càrrega a la xarxa, canviarà el preu del gas, és a dir, el coeficient segons el qual es convertirà la moneda base en aquesta unitat auxiliar per pagar la comissió.
Hi ha una característica més d'una transacció a Ethereum: el bytecode que conté per a l'execució en una màquina virtual s'executarà fins que es completi amb algun resultat (èxit o fracàs) o fins que s'esgoti una determinada quantitat de monedes assignades per pagar la comissió. . És per evitar una situació en què, en cas d'error, totes les monedes del compte del remitent es van gastar en comissió (per exemple, algun tipus de cicle etern iniciat en una màquina virtual), existeix el següent camp: arrencar el gas (sovint anomenada límit de gas): determina la quantitat màxima de monedes que el remitent està disposat a gastar per completar una determinada transacció.
El següent camp es diu adreça de destinació. Això inclou l'adreça del destinatari de les monedes o l'adreça d'un contracte intel·ligent específic els mètodes del qual s'anomenaran. Després ve el camp valor, on s'introdueix la quantitat de monedes que s'envien a l'adreça de destinació.
El següent és un camp interessant anomenat dades, on encaixa tota l'estructura. No es tracta d'un camp separat, sinó de tota una estructura en la qual es defineix el codi de la màquina virtual. Aquí podeu col·locar dades arbitràries; hi ha regles separades per a això.
I l'últim camp es diu signatura. Conté simultàniament tant la signatura electrònica de l'autor d'aquesta transacció com la clau pública amb la qual es verificarà aquesta signatura. Des de la clau pública es pot obtenir l'identificador del compte del remitent d'aquesta transacció, és a dir, identificar de manera única el compte del remitent al propi sistema. Vam descobrir el més important sobre l'estructura de la transacció.
Exemple de codi de contracte intel·ligent per a Solidity
Mirem ara de prop el contracte intel·ligent més senzill fent servir un exemple.
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);
}
}A dalt hi ha un codi font simplificat que pot contenir les monedes dels usuaris i tornar-les sota demanda.
Així doncs, hi ha un contracte intel·ligent del banc que realitza les funcions següents: acumula monedes al seu saldo, és a dir, quan es confirma una transacció i es col·loca aquest contracte intel·ligent, es crea un nou compte que pot contenir monedes al seu saldo; recorda els usuaris i la distribució de monedes entre ells; disposa de diversos mètodes per gestionar els saldos, és a dir, és possible reposar, retirar i comprovar el saldo de l'usuari.
Repassem cada línia de codi font. Aquest contracte té camps constants. Un d'ells, amb adreça tipus, s'anomena propietari. Aquí el contracte recorda l'adreça de l'usuari que ha creat aquest contracte intel·ligent. A més, hi ha una estructura dinàmica que manté la correspondència entre les adreces dels usuaris i els saldos.
Això és seguit pel mètode del banc: té el mateix nom que el contracte. En conseqüència, aquest és el seu constructor. Aquí s'assigna a la variable propietari l'adreça de la persona que va col·locar aquest contracte intel·ligent a la xarxa. Això és l'únic que passa en aquest constructor. És a dir, msg en aquest cas són exactament les dades que es van transferir a la màquina virtual juntament amb la transacció que conté tot el codi d'aquest contracte. En conseqüència, msg.sender és l'autor d'aquesta transacció que allotja aquest codi. Serà el propietari del contracte intel·ligent.
El mètode de dipòsit us permet transferir un nombre determinat de monedes al compte del contracte per transacció. En aquest cas, el contracte intel·ligent, en rebre aquestes monedes, les deixa al seu balanç, però registra a l'estructura de balanços qui va ser exactament l'emissor d'aquestes monedes per saber a qui pertanyen.
El següent mètode s'anomena retirar i es necessita un paràmetre: la quantitat de monedes que algú vol retirar d'aquest banc. Això comprova si hi ha prou monedes al saldo de l'usuari que crida a aquest mètode per enviar-les. Si n'hi ha prou, el contracte intel·ligent en si torna aquest nombre de monedes a la persona que truca.
A continuació ve el mètode per comprovar el saldo actual de l'usuari. Qui cridi aquest mètode s'utilitzarà per recuperar aquest saldo al contracte intel·ligent. Val la pena assenyalar que el modificador d'aquest mètode és la vista. Això vol dir que el mètode en si no canvia les variables de la seva classe de cap manera i en realitat només és un mètode de lectura. No es crea cap transacció separada per trucar a aquest mètode, no es paga cap quota i tots els càlculs es realitzen localment, després del qual l'usuari rep el resultat.
El mètode kill és necessari per destruir l'estat del contracte intel·ligent. I aquí hi ha una comprovació addicional de si la persona que truca d'aquest mètode és el propietari d'aquest contracte. Si és així, el contracte s'autodestrueix i la funció de destrucció pren un paràmetre: l'identificador del compte al qual el contracte enviarà totes les monedes que queden al seu saldo. En aquest cas, les monedes restants aniran automàticament a l'adreça del titular del contracte.
Com funciona un node complet a la xarxa Ethereum?
Vegem esquemàticament com s'executen aquests contractes intel·ligents a la plataforma Ethereum i com funciona un node de xarxa complet.
Un node complet a la xarxa Ethereum ha de tenir almenys quatre mòduls.
El primer, com per a qualsevol protocol descentralitzat, és el mòdul de xarxa P2P: un mòdul per a la connexió a la xarxa i el treball amb altres nodes, on s'intercanvien blocs, transaccions i informació sobre altres nodes. Aquest és un component tradicional per a totes les criptomonedes descentralitzades.
A continuació, tenim un mòdul per emmagatzemar dades de blockchain, processar, triar una branca prioritària, afegir blocs, desenllaçar blocs, validar aquests blocs, etc.
El tercer mòdul s'anomena EVM (Ethereum virtual machine): aquesta és una màquina virtual que rep el codi de bytes de les transaccions d'Ethereum. Aquest mòdul pren l'estat actual d'un compte particular i fa canvis al seu estat en funció del bytecode rebut. La versió de la màquina virtual a cada node de xarxa ha de ser la mateixa. Els càlculs que es fan a cada node d'Ethereum són exactament els mateixos, però es produeixen de manera asíncrona: algú verifica i accepta aquesta transacció abans, és a dir, executa tot el codi que hi conté, i algú més tard. En conseqüència, quan es crea una transacció, es distribueix a la xarxa, els nodes l'accepten i, en el moment de la verificació, de la mateixa manera que s'executa Bitcoin Script a Bitcoin, aquí s'executa el bytecode de la màquina virtual.
Una transacció es considera verificada si s'ha executat tot el codi que hi conté, s'ha generat un nou estat d'un determinat compte i s'ha desat fins que quedi clar si aquesta transacció s'ha aplicat o no. Si s'aplica la transacció, aquest estat no només es considera completat, sinó també actual. Hi ha una base de dades que emmagatzema l'estat de cada compte per a cada node de xarxa. A causa del fet que tots els càlculs es produeixen de la mateixa manera i l'estat de la cadena de blocs és el mateix, la base de dades que conté els estats de tots els comptes també serà la mateixa per a cada node.
Mites i limitacions dels contractes intel·ligents
Pel que fa a les restriccions que existeixen per a plataformes de contracte intel·ligent similars a Ethereum, es poden citar les següents:
- execució de codi;
- assignar memòria;
- dades de blockchain;
- enviar pagaments;
- crear un nou contracte;
- trucar a altres contractes.
Vegem les restriccions que s'imposen a una màquina virtual i, en conseqüència, dissiminem alguns mites sobre els contractes intel·ligents. En una màquina virtual, que no només pot estar a Ethereum, sinó també en plataformes similars, podeu realitzar operacions lògiques realment arbitràries, és a dir, escriure codi i s'executarà allà, també podeu assignar memòria. No obstant això, la quota es paga per separat per cada operació i per cada unitat addicional de memòria assignada.
A continuació, la màquina virtual pot llegir dades de la base de dades blockchain per utilitzar aquestes dades com a activador per executar una o una altra lògica de contracte intel·ligent. La màquina virtual pot crear i enviar transaccions, pot crear nous contractes i mètodes de trucada d'altres smart contracts que ja estan publicats a la xarxa: existents, disponibles, etc.
El mite més comú és que els contractes intel·ligents d'Ethereum poden utilitzar informació de qualsevol recurs d'Internet segons els seus termes. El cert és que una màquina virtual no pot enviar una sol·licitud de xarxa a algun recurs d'informació extern a Internet, és a dir, és impossible redactar un contracte intel·ligent que distribueixi valor entre usuaris en funció, per exemple, del clima que faci fora, o qui va guanyar algun campionat, o en funció de quin altre incident va passar a l'exterior, perquè la informació sobre aquests incidents simplement no es troba a la base de dades de la pròpia plataforma. És a dir, no hi ha res a la cadena de blocs sobre això. Si no hi apareix, la màquina virtual no pot utilitzar aquestes dades com a activadors.
Desavantatges d'Ethereum
Enumerem els principals. El primer desavantatge és que hi ha algunes dificultats per dissenyar, desenvolupar i provar contractes intel·ligents a Ethereum (Ethereum utilitza el llenguatge Solidity per escriure contractes intel·ligents). De fet, la pràctica demostra que un percentatge molt gran de tots els errors pertanyen al factor humà. Això és cert per als contractes intel·ligents d'Ethereum ja escrits que tenen una complexitat mitjana o superior. Si per als contractes intel·ligents simples la probabilitat d'un error és petita, aleshores en els contractes intel·ligents complexos hi ha molt sovint errors que condueixen al robatori de fons, la seva congelació, la destrucció de contractes intel·ligents de manera inesperada, etc. Molts d'aquests casos ja són conegut.
El segon inconvenient és que la pròpia màquina virtual no és perfecta, ja que també està escrita per persones. Pot executar ordres arbitràries, i aquí rau la vulnerabilitat: es poden configurar d'una manera determinada una sèrie d'ordres que donaran lloc a conseqüències que no s'havien previst per endavant. Es tracta d'una àrea molt complexa, però ja hi ha diversos estudis que demostren que aquestes vulnerabilitats existeixen a la versió actual de la xarxa Ethereum i poden provocar el fracàs de molts contractes intel·ligents.
Una altra gran dificultat, es pot considerar un desavantatge. Rau en el fet que pràcticament o tècnicament podeu arribar a la conclusió que si compileu el bytecode d'un contracte que s'executarà en una màquina virtual, podeu determinar algun ordre específic d'operacions. Quan es realitzen conjuntament, aquestes operacions carregaran molt la màquina virtual i la frenaran de manera desproporcionada a la tarifa que es va pagar per realitzar aquestes operacions.
En el passat, ja hi va haver un període en el desenvolupament d'Ethereum, quan molts nois que van entendre detalladament el funcionament d'una màquina virtual van trobar aquestes vulnerabilitats. De fet, les transaccions pagaven una tarifa molt petita, però pràcticament van frenar tota la xarxa. Aquests problemes són molt difícils de resoldre, ja que cal, en primer lloc, determinar-los, en segon lloc, ajustar el preu per realitzar aquestes operacions i, en tercer lloc, dur a terme un hard fork, que suposa actualitzar tots els nodes de la xarxa a una nova versió. del programari, i després activació simultània d'aquests canvis.
Pel que fa a Ethereum, s'ha fet molta investigació, s'ha adquirit molta experiència pràctica: tant positiva com negativa, però, tanmateix, queden dificultats i vulnerabilitats que encara s'han de resoldre d'alguna manera.
Així doncs, la part temàtica de l'article s'ha completat, passem a les preguntes que sorgeixen amb força freqüència.
Часто задаваемые вопросы
— Si totes les parts d'un contracte intel·ligent existent volen canviar els termes, poden cancel·lar aquest contracte intel·ligent mitjançant multisig i, a continuació, crear un nou contracte intel·ligent amb les condicions actualitzades de la seva execució?
La resposta aquí serà doble. Per què? Perquè d'una banda, un contracte intel·ligent es defineix una vegada i ja no implica cap canvi, i de l'altra, pot tenir una lògica prèviament escrita que preveu un canvi total o parcial d'algunes condicions. És a dir, si voleu canviar alguna cosa al vostre contracte intel·ligent, heu de prescriure les condicions en què podeu actualitzar aquestes condicions. En conseqüència, només d'una manera tan prudent es pot organitzar la renovació del contracte. Però aquí també pots tenir problemes: cometre algun error i obtenir una vulnerabilitat corresponent. Per tant, aquestes coses han de ser molt detallades i dissenyades i provades amb cura.
— Què passa si el mediador arriba a un acord amb una de les parts participants: escrow o smart contract? Es requereix un mediador en un contracte intel·ligent?
No es requereix un mediador en un contracte intel·ligent. Potser no existeix. Si, en el cas de l'escrow, el mediador entra en una conspiració amb una de les parts, llavors sí, aquest esquema perd bruscament tot el seu valor. Per tant, els mediadors es seleccionen de manera que totes les parts implicades en aquest procés confien en ells alhora. En conseqüència, simplement no transferiràs monedes a una adreça multisignatura amb un mediador en el qual no confies.
— És possible amb una transacció d'Ethereum transferir molts testimonis diferents de la vostra adreça a diferents adreces de destinació, per exemple, adreces d'intercanvi on es comercialitzen aquests fitxes?
Aquesta és una bona pregunta i es refereix al model de transacció Ethereum i en què es diferencia del model de Bitcoin. I la diferència és radical. Si en el model de transacció Ethereum simplement transferiu monedes, només es transfereixen d'una adreça a una altra, sense canvis, només la quantitat específica que heu especificat. En altres paraules, no es tracta d'un model de sortides no gastades (UTXO), sinó d'un model de comptes i saldos corresponents. En teoria, és possible enviar diverses fitxes diferents en una transacció alhora si escriviu un contracte intel·ligent astut, però encara haureu de fer moltes transaccions, crear un contracte, transferir-hi fitxes i monedes i, a continuació, trucar al mètode adequat. . Això requereix esforç i temps, de manera que a la pràctica no funciona així i tots els pagaments a Ethereum es fan en transaccions separades.
— Un dels mites sobre la plataforma Ethereum és que és impossible descriure condicions que dependran de les dades d'un recurs extern d'Internet, llavors què fer?
La solució és que el contracte intel·ligent en si pot proporcionar un o més els anomenats oracles de confiança, que recullen dades sobre l'estat de les coses al món exterior i les transmeten als contractes intel·ligents mitjançant mètodes especials. El mateix contracte considera certes les dades que va rebre de parts de confiança. Per a una major fiabilitat, simplement trieu un gran grup d'oracles i minimitzeu el risc de la seva connivència. El contracte en si no pot tenir en compte dades d'oracles que contradiguin la majoria.
Una de les conferències del curs en línia sobre Blockchain està dedicada a aquest tema - "".
Font: www.habr.com