Esta nueva publicación presenta los elementos de la arquitectura de referencia de New Golem e ilustra cómo interactúan para formar un ecosistema funcional.
En las partes anteriores de esta publicación de blog ( Parte I y Parte II ) hemos introducido los conceptos fundamentales del mercado de New Golem y el lenguaje genérico de Demanda y Especificación de Oferta.
Esta nueva publicación presenta los elementos de la arquitectura de referencia de New Golem e ilustra cómo interactúan para formar un ecosistema funcional. Este es un conocimiento básico importante que debe tener, antes de profundizar en los detalles de las API de Golem de bajo nivel (Interfaces de programación de aplicaciones, acrónimo de intermediarios de software que permiten que dos aplicaciones se comuniquen entre sí).
Daemon y CLI (interfaz de línea de comandos)
Para participar en la red Golem, una máquina debe alojar un componente llamado Daemon. El Daemon es una pieza de software que se ejecuta en segundo plano e implementa todas las mecánicas fundamentales del ecosistema Golem. Es responsable de:
- Gestión de claves, cuentas e identidad de nodo
- Comunicación con otros nodos de la red Golem.
- Implementación de las API de bajo nivel
- Gestión de pagos e integración con plataformas de pago (sí, la nueva arquitectura Golem permite varias plataformas de pago, como soluciones simples de Ethereum o Layer-2)
Entonces, el Daemon será el primer componente que debe estar en un nodo Golem. Implementa API y características tanto del Solicitante como del Proveedor.
La arquitectura de referencia incluye una CLI para controlar el estado del Daemon y varias de sus funciones administrativas. Entonces, usó una CLI para configurar la instancia de Daemon, y ahora está listo para ejecutar las aplicaciones del Agente …
Agente proveedor
Para anunciar recursos en el Mercado Golem, las Ofertas deben publicarse y las Demandas entrantes procesadas, de modo que se puedan negociar los Acuerdos con los Solicitantes. Luego, se debe controlar la ejecución de la actividad y, finalmente, se deben emitir notas de pago para recibir pagos por servicios. Todas estas responsabilidades son del dominio de la aplicación del Agente en el lado del Proveedor.
Entonces, como Proveedor, usted inicia y configura sus aplicaciones de Agente Proveedor y les permite hacer todo el mercado, la ejecución y el control de pagos.
Aplicación de agente solicitante
Ahora que desarrollamos el agente proveedor, ¿qué componente es responsable de formular la demanda de recursos informáticos disponibles en la red Golem? Hay una aplicación en el lado del Solicitante, que «sabe lo que quiere», es decir. coloca la especificación de los recursos requeridos, así como los términos comerciales aceptables, en lo que llamamos una Demanda, y la emite al mercado Golem (utilizando las API publicadas por Daemon).
A medida que las Ofertas coincidentes llegan del mercado, esta aplicación de Agente Solicitante selecciona a los Proveedores candidatos en función de su estrategia de mercado, lleva a cabo negociaciones y confirma el Acuerdo. Posteriormente, controla la ejecución y valida los resultados para aceptar las facturas entrantes.
Las Aplicaciones del Agente Solicitante probablemente serán específicas de un caso de uso, es decir. adaptado para una tarea específica, o al menos junto con un tipo de ExeUnit específico.
ExeUnits
Todos los recursos informáticos ofrecidos en la red Golem están envueltos por una interfaz abstracta que permite controlar la ejecución y consultar el estado de la ejecución. Llamamos a las instancias de esta abstracción entornos de ejecución o ExeUnits.
Después de que se firma un Acuerdo (que autoriza al Solicitante a utilizar los recursos ofrecidos por el Proveedor), se crea una Actividad. Como parte de esta actividad, se lanza una instancia de ExeUnit y las API de Golem permiten al solicitante controlar la ejecución de la carga útil en esta instancia de ExeUnit.
Piense en ExeUnit como un host que es capaz de, por ejemplo,. ejecutar módulos binarios en un formato determinado. Entonces podemos tener, por ejemplo. WASM ExeUnits (capaces de ejecutar módulos WASM), VM ExeUnits (capaces de ejecutar máquinas VM en las que se pueden implementar y ejecutar paquetes de software, etc.)
Los atributos y parámetros de ExeUnits se especifican a través de sus Propiedades (¿recuerdas el lenguaje de especificación descrito en la publicación anterior?). Es a través de las Propiedades en una Oferta que los Proveedores indican que están dispuestos a alojar la carga útil en una ExeUnit determinada. Y es a través de las restricciones contra esas Propiedades en una Demanda, que los Solicitantes anuncian sus requisitos. Esto también explica cómo se puede negociar una variedad de diferentes tipos de recursos informáticos en un mercado abierto de Golem.
… todo esto junto
Todos los módulos descritos anteriormente, trabajando juntos, forman la red lógica de Golem. Golem Factory está construyendo actualmente una implementación de esta arquitectura de referencia; la llamamos Yagna:
El diagrama anterior indica las relaciones de alto nivel entre los módulos de Yagna. La próxima publicación revelará algunos detalles sobre las API publicadas por Daemon, y cómo esas API manejan un modelo de flujo de “negociación-ejecución-pago”.
Para obtener más información sobre Golem, visite nuestro sitio web
