Actualizaciones inteligentes vs contratos inteligentes

¿Qué es un contrato inteligente y por qué se necesitaba?

Hace mucho tiempo, después de la aparición de Bitcoin, la primera máquina de estado replicada, la gente comenzó a notar que la funcionalidad incorporada en el consenso es demasiado limitada. No estoy hablando de agregar códigos criptográficos al comercio, sino de casos de usuarios de la vida real: DNS donde cada dominio pertenece a una clave pública y no a un registrador centralizado, todo tipo de tokens y derivados financieros (porque desea poseer acciones de la misma manera que posee Bitcoin), intercambios onchain (para comerciar en grandes cantidades sin confianza en el intercambio), canales de pago (redistribuir rápidamente la custodia general entre dos cuentas sin una sobrecarga de un mensaje de transacción en general) ...

Había tres formas de agregar funciones:

1) lo más obvio es ingresarlos en el código de la cadena de bloques en sí, de forma nativa.

Blockchain es esencialmente un sitio web replicado , cuando no tiene suficientes funciones en el sitio web, ¿qué está haciendo? Simplemente agréguelo directamente al código como un nuevo modelo o controlador . Pero en el caso de una red descentralizada, no existe un proceso para tal cambio en los modelos / controladores; después de todo, se puede utilizar para su ventaja. Solo una opción de hard fork, donde todos al mismo tiempo acuerdan chats / foros.

2) crea otra cadena de bloques con esta funcionalidad.

Así que sucedió con varias "blockchains de una idea" ala namecoin. Pronto se notó que las personas no quieren usar la nueva red para una función, también necesitan interoperabilidad y muchas cosas dependen unas de otras (los préstamos, las identidades y los activos quieren vivir en el mismo espacio de direcciones)

3) implementar funciones utilizando la máquina virtual interna y los códigos de operación.

Incluso Satoshi puso Script en Bitcoin precisamente por el problema de actualización, que permitió hacer mucho, pero no fue suficiente. Por lo tanto, ether propuso un script extendido (ahora completo), y supuestamente puede hacer cualquier cosa con él (en teoría).


Entonces, es el código ejecutado por la máquina virtual dentro de la cadena de bloques que se llama contrato inteligente, y es necesario para implementar nuevas funciones. Puede llamarlo un "parche de código de operación", pero no se vende tan bien :)

¿Qué es una actualización inteligente?

En cuanto a los contratos inteligentes durante los últimos años, podemos decir claramente que no cumplieron con las expectativas. Sí, el boom de ICO no fue posible en bitcoin, pero introducir un EVM avanzado solo para tokens erc20 fue demasiado.

Escribir incluso un pequeño "parche" en solidez es extremadamente difícil. En el nivel inferior, encontrará una máquina virtual sin formato que tiene muy pocos códigos de operación (por diseño) y una base de datos simple de valores clave. Todas las operaciones son extremadamente caras (costo de la gasolina) y no se puede cambiar en absoluto.

Los casos de usuario sofisticados son casi imposibles. Eche un vistazo a github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts : miles de líneas de código, en el idioma extranjero (solidez), para administrar un sistema financiero complejo. Vimos varios hacks de paridad y DAO con ataques simples, ¿qué tipo de ataques nos esperan en una base de código tan monstruosa?

No hay una base de datos SQL, NoSQL no está presente, la base de datos gráfica tampoco está planificada. ¿Iteración clave, muchos a muchos? ORM? Nada de esto existe dentro del contrato. Las herramientas también son muy débiles en relación con los lenguajes de programación conocidos.

El 95% del trabajo de un proyecto moderno de solidez es precisamente la lucha contra la solidez y no la arquitectura del código. La misma idea se puede implementar en javascript diez veces más rápido y más confiable, simplemente porque sabemos y podemos escribir javascript y el ecosistema de solidez no ha ido mucho más allá que el ecosistema de brainfuck.

En defensa de EVM, todavía diré: la imagen en el mundo de bitcoin es aún más triste ya que su ajuste es aún más débil y los códigos de operación aún más pequeños . Los desarrolladores de Lightning muerden pero aún tienen un cactus: la complejidad de un canal de bitcoin bidireccional en Bitcoin es tan loca que mantener el código base es aún más difícil, y cosas convenientes como Sprites y lógica compleja dentro del canal de estado son simplemente imposibles.

Gobierno de Onchain = Actualizaciones inteligentes

Después de hartarse del dolor con solidez, volvamos a 2012 y recordemos la primera opción descartada con la adición de casos de usuarios de forma nativa a la cadena de bloques.


Como muchos han notado, después de la implementación de EVM, EVM en sí no dejó de actualizarse como se suponía (el nivel base nunca cambia, todo el código nuevo solo está dentro de EVM); por el contrario, se bifurca regularmente con la dictadura del ethereum.

Es decir los mismos huevos solo de perfil. Un grupo de personas decide cómo cambiar la capa onchain con sus propias manos, coloca el código en un github y todos los usuarios no tienen más remedio que descargar un nuevo código. "La bifurcación dura está programada para el viernes, actualice de inmediato", nos dicen.

De esta forma, la idea de contratos inteligentes es absolutamente un fracaso: ya tenemos autoridad que dicta cómo funciona la capa de consenso (cuenta github de ethereum), ¿para qué sirve una abstracción adicional e ineficaz si no pudiéramos deshacernos de las actualizaciones de la capa principal?

Como no podemos deshacernos de las actualizaciones, al menos descubramos cómo actualizarnos esta capa principal de la manera más descentralizada posible.

Podemos ofrecer parches de software dentro de la cadena de bloques, los validadores pueden votar por ellos, y los parches ganadores simplemente se implementan sincrónicamente para todos después de un período. Esta idea de "gobernanza en cadena" ha estado en el aire durante bastante tiempo, pero Tezos fue el primero en describirla, si no me equivoco. Lo que los tezos perdieron de vista es que el gobierno de onchain es un competidor directo de los contratos inteligentes (por eso lo llamo actualizaciones inteligentes).

Si tiene actualizaciones inteligentes, simplemente no necesita contratos inteligentes. Cualquier caso de usuario se puede implementar más rápido, mejor, con cualquier base de datos de su elección (SQL / NoSQL / lo que sea), en cualquier lenguaje de programación (ya ejecuta el código a nivel de máquina y no está limitado a nada). Libertad total, menos el 95% de gastos generales que gastó en solidez, y no necesitamos esculpir una nueva cadena de bloques como solución # 2.

Hay exactamente dos desventajas para las actualizaciones inteligentes

1. Ahora, no todos los casos de usuarios serán aprobados por los validadores, ya que piensan y votan qué tipo de parche será útil para la red (y cortan las puertas traseras francamente maliciosas). Es poco probable que cosas como las criptomonedas sean aprobadas por la mayoría (un 67% o 95% de almacenamiento, configurado dentro de la propia red)

2. Los validadores pueden usar esta fuerza para abrir parches que son directamente beneficiosos para ellos (eliminar a un usuario objetable, dejarse obtener activos de tres cajas). Para resolver este problema, hay un período de retraso. Una vez aprobado el parche, toda la red tiene de 2 a 6 semanas para estudiar. Si a los usuarios comunes no les gusta, la gente debería reunirse, hacer un hard fork y reemplazar el conjunto de validadores por otros más adecuados (o descartar los peores caracteres).

Suena aterrador, pero ya funciona así : athereum github puede ofrecer absolutamente cualquier bifurcación y esta es la tarea de los usuarios para restablecer la dictadura si no les gusta algo. No empeorará. Simplemente formalizamos este proceso y le damos filetes transparentes a cada desarrollador / validador, en lugar del gobierno "sombra" existente con el primer canal en forma de un repositorio github.

Resumen

Por lo tanto, descubrimos que los contratos inteligentes EVM es un concepto interesante que resultó ser un fracaso, un giro demasiado pesado en la dirección equivocada, cuando todo lo que se requería era implementar un mecanismo transparente para actualizaciones inteligentes para resolver el problema de los nuevos casos de usuarios.

El futuro es para actualizaciones inteligentes, y casi todas las cadenas de bloques que están actualmente en desarrollo las incluyen desde el principio (tezos, dfinity, polkadot, decred, tendermint, fairlayer, etc.). Incluso en los contratos inteligentes mismos, ahora están tratando de activar el mecanismo de actualización dentro de sí mismos, dándose cuenta de que el concepto de incrustación no funciona, y de alguna manera tarde o temprano será necesario actualizar .

Aquí hay una wiki más detallada sobre este tema (en inglés. Estoy sorprendido de cómo Vitalik y Vlad Zamfir intentan denigrar las actualizaciones inteligentes , su competidor directo hace que EVM sea completamente obsoleto.