¿Y si una transacción pudiera demostrar que cumple tus reglas antes de que tu contrato inteligente la toque?
@NewtonProtocol insiste en la idea de que la autorización debe ocurrir antes de la ejecución, no después. Eso parece algo pequeño, pero cambia dónde los desarrolladores depositan la confianza. En lugar de poner cada condición directamente dentro de un contrato, Newton permite que una política decida si una transacción merece avanzar.
La tensión práctica $UP
La mayoría de los contratos inteligentes son estáticos una vez desplegados.
Las reglas de negocio no lo son.
Un límite de gasto cambia. Un requisito de cumplimiento cambia. El estado de una cartera cambia. Actualizar Solidity cada vez es lento y costoso. Newton lo aborda de manera diferente al separar las reglas de transacción de la lógica del contrato.
Lo que destaca
•Dato: Newton evalúa los intents de transacciones antes de la ejecución mediante un flujo de políticas, en lugar de comprobarlo todo dentro de Solidity.
•Dato: Las políticas pueden usar información externa proporcionada mediante oráculos de datos WebAssembly (WASM) antes de tomar una decisión.
•Dato: Los operadores devuelven atestaciones criptográficas, que son verificadas por el PolicyClient en cadena antes de la ejecución.
•Opinión: Lo interesante no es el lenguaje de la política. Es reducir la cantidad de razones por las que un contrato necesita volver a desplegarse cuando evolucionan las reglas del negocio.
Una observación a la que sigo volviendo
#Newt no intenta que los contratos sean más complicados.
Está intentando hacer que sean menos responsables.
El contrato principalmente verifica una atestación. La decisión en sí ya se evaluó en otro lugar bajo reglas predefinidas.
Eso crea una separación más limpia entre ejecución y autorización.
Si eso se convierte en una ventaja depende de la aplicación.
Los números que vale la pena notar
•Alrededor de 30 minutos para construir un oráculo de datos WASM.
•Alrededor de 20 minutos para escribir una política Rego.
•Alrededor de 15 minutos para el despliegue vía CLI.
•Alrededor de 30 minutos para cada una: integración de contratos inteligentes e integración del SDK de frontend.
Estas son estimaciones de la documentación, no garantías. Los proyectos reales normalmente tardan más según las pruebas y las revisiones de seguridad.
Evtakeaway
•Newton permite a los desarrolladores desplegar políticas por separado de los contratos.
•Newton admite entradas de datos externas durante la evaluación de la política.
•Newton verifica en cadena las atestaciones firmadas con BLS antes de la ejecución.
•El despliegue de políticas en mainnet requiere allowlisting en lugar de un despliegue completamente sin permisos.
Esos detalles sugieren que Newton espera que la infraestructura de autorización se trate como crítica para producción, en lugar de como una función opcional.
Dónde creo que Newton se vuelve interesante
Imagina un tesoro con un límite diario de transferencias.
Mañana el consejo decide los cambios en el límite.
Sin Newton, los desarrolladores podrían volver a desplegar contratos o añadir complejidad de gobernanza.
Con Newton, los cambios de política ocurren mientras el contrato de ejecución permanece igual.
Eso no elimina la gobernanza.
Eso cambia dónde ocurre la gobernanza.
Pequeña distinción.
Potencialmente significativo.
Lo que verificaría antes de construir sobre Newton
•¿De dónde provienen realmente los datos externos?
•¿Quién opera la fuente de datos?
•¿Con qué frecuencia se actualiza esa información?
•¿Puede cambiar la lógica de la política sin afectar suposiciones existentes?
•¿Quién controla las actualizaciones de políticas?
•¿Las atestaciones son fáciles de auditar de forma independiente?
•¿La implementación de PolicyClient ha recibido auditorías de seguridad?
•¿Qué pasa si la evaluación de la política se vuelve temporalmente no disponible?
Estas preguntas importan más que si el SDK se siente conveniente.
Riesgos que vale la pena mantener a la vista
•Riesgo de contrato inteligente: Incluso si Newton valida correctamente las atestaciones, los contratos de aplicación aún pueden contener errores de implementación.
•Riesgo de dependencia externa: Las decisiones de políticas dependen de la evaluación fuera de la cadena y de la disponibilidad de datos. Si falla la infraestructura de soporte, la autorización de transacciones podría retrasarse.
•Riesgo operativo: La gobernanza sobre las actualizaciones de políticas se convierte en una suposición de seguridad importante.
•Estimaciones de la documentación: Los tiempos de integración son números de referencia, no cronogramas de producción.
Los diseños equilibrados rara vez eliminan el riesgo.
Por lo general, la mueven a algún otro lugar.
Mi conclusión $ARX
$NEWT feels menos como otro kit de herramientas de contratos inteligentes y más como un intento de separar quién decide de quién ejecuta. Esa separación podría simplificar algunas aplicaciones mientras introduce nuevas suposiciones operativas. Si ese intercambio vale la pena probablemente dependa menos de Newton en sí y más de cuánto espera tu proyecto que cambien sus reglas de autorización después del despliegue. Esa es la parte a la que seguiría prestando atención.