La máquina virtual de Aion (AVM) es un componente del software que se ejecuta en las máquinas que mantienen la red pública de de Aion. Específicamente, es la parte que ejecuta los programas que los usuarios pueden almacenar en la cadena de bloques.
La distinción clave de la AVM, en comparación con las máquinas virtuales en muchas otras cadenas de bloques, es que la AVM puede ejecutar programas de cadena de bloques ("contratos inteligentes") escritos en el lenguaje de programación Java.
Para obtener más información, consulte este artículo donde presentamos el uso de AVM para ejecutar código Java en la cadena de bloques.
Bienvenidos desarrolladores de Java
La mayor noticia aquí es, obviamente, para la comunidad de Java, en sí misma. Ahora pueden construir contratos inteligentes directamente en Java.
Además, el complemento BloxBean Aion4J Maven hace que la prueba / implementación / llamada de contratos inteligentes sea fácil de integrar en un sistema de compilación existente.
Además, el complemento BloxBean IntelliJ significa que se puede utilizar un IDE Java familiar para ayudar en el desarrollo, las pruebas, la implementación y la depuración. Sí, incluso depuración! El complemento IntelliJ ejecuta el AVM internamente, por lo que puede depurar contratos inteligentes de Java con soporte completo de depuración (puntos de interrupción, introspección de variables, etc.), directamente en el IDE.
Estas herramientas se describen con mayor detalle en el sitio de Aion Docs:
Maven y Aion4JIntelliJ Plugin
Algunas de las nuevas capacidades de AVM también pueden ser de interés para los desarrolladores de existentes:
Modelo de programación orientado a objetos de Java, que incluye tipos personalizados. Ecosistema y herramientas y patrones de Java. Tipos de datos primitivos rápidos y económicos. Modelo de almacenamiento híbrido: un almacén de valores clave y un gráfico de objetos transparente. Compatibilidad con punto flotante IEEE 754
Beneficios AVM más amplios
Este es un gran problema en términos de lo que se puede ejecutar en una cadena de bloques pública, por lo que aquellos interesados en el futuro de tales sistemas definitivamente deberían tomar nota de la AVM.
El AVM ofrece un camino completamente nuevo para construir software en cadena. Por supuesto, se trata de construir contratos inteligentes en Java estándar.
Esto significa que el ecosistema más amplio de patrones y herramientas de desarrollo son potencialmente candidatos para su uso en un entorno de , como en el caso de los complementos antes mencionados de Maven e IntelliJ creados por BloxBean.
Más allá de eso, el AVM también abre la puerta a nuevas mejoras de rendimiento en los nodos que ejecutan la cadena, lo que crea la posibilidad de permitir bloques más complejos en el futuro (piense en límites de energía de bloque total más altos). Parte de esto se debe a nuestra capacidad de capitalizar el rendimiento de la JVM, pero parte también proviene de nuestro nuevo modelo de almacenamiento híbrido, y mucho de nuestra capacidad para ejecutar transacciones concurrentemente.
Haciendo todos los DB esperando a la vez.
Tenga en cuenta que demostramos este beneficio de ejecución de transacciones concurrentes antes de la bifurcación, donde cambiamos a usar el AVM para transferencias de saldo, nuevamente en el kernel de Java 0.3.4. Al ejecutar varias transacciones al mismo tiempo, podemos ocultar el tiempo dedicado a esperar por el DB.
El futuro de AVM
Ahora que tenemos AVM a nuestra disposición, aquí están algunas de nuestras ideas futuras (ninguna de estas está grabada en piedra, solo las posibilidades que estamos considerando):
Otra compatibilidad con el lenguaje JVM: todo lo que necesitaríamos es crear versiones reforzadas con de las bibliotecas de tiempo de ejecución que estos lenguajes requieren y verificar que no tienen otras suposiciones ocultas que necesitaríamos para apoyar / restringir de manera más directa. Optimizaciones: Ya hemos realizado algunos cambios para mejorar algunos de los peores escenarios de costos de ejecución internos y tenemos otros experimentos para tratar de ocultar aún más el costo de ir a la DB. Herramientas del lado del cliente: Ya compilamos el ABI, en el lado del cliente, y estamos en medio de la expansión de esta canalización del lado del cliente para reducir aún más los costos de implementación. Bibliotecas más pequeñas para usuarios: para mantener el área de la superficie de la AVM pequeña, se ofrece mucha funcionalidad como bibliotecas para usuarios, que se empaquetan junto con el contrato, cuando se implementan . Algunos de estos son más sofisticados de lo que deben ser (son una retención de un conjunto diferente de supuestos), por lo que bastarían con otros más pequeños y ahorrarían en costos de implementación.
Dado que estos están empaquetados con el contrato, no tenemos que esperar a que un tenedor firme los cambie (y los usuarios son libres de hacerlos ellos mismos). Facilidad de expansión de API: las nuevas características que apuntan a los contratos inteligentes serán fáciles de exponer en el AVM, ya que expone la funcionalidad de como llamadas API normales, a diferencia de los opcodes de casos especiales en el nivel de VM. Esto significa que podemos ampliar la funcionalidad sin modificar el resto de la pila de herramientas (de manera muy similar a la forma en que JVM expande su biblioteca de clases principal con nuevas clases y funciones).
Por supuesto, también hay algunas posibilidades más exóticas, al considerar lo que VM puede hacer, pero tendré que dejar eso a su imaginación ya que no estamos seguros de lo que se requerirá, todavía. Basta con decir que tenemos muchas ideas en caso de que tengamos la oportunidad de explorarlas en el futuro.
El futuro se ve brillante!
