Imagine un escenario en el que una plataforma blockchain se está desarrollando rápidamente y el número de usuarios está explotando, llegando rápidamente a decenas de millones, lo que genera un fuerte aumento en los costos relacionados en un corto tiempo. 

En esta etapa, ¿qué estrategias son necesarias para mantener la eficiencia operativa sin obstaculizar el ritmo de desarrollo debido a los complejos procesos de consenso y confirmación? Como las empresas están de acuerdo, la escalabilidad tiene que ser una prioridad.

Como tecnología de escalabilidad fuera de la cadena, Ontology Layer 2 ofrece un mayor rendimiento y tasas más bajas. 

Las empresas pueden almacenar de forma segura una gran cantidad de registros de transacciones fuera de la cadena y luego transferirlos a la cadena cuando necesiten interactuar, reduciendo los costos de transacción del usuario y aumentando drásticamente el rendimiento.

Introducción

Como se describe en la hoja de ruta de Aristóteles 2020, junto con la cadena cruzada de Ontology, Wasm-JIT, Multi-VM y otras tecnologías centrales de vanguardia, Ontology Layer 2 ahora muestra un rendimiento líder en contraste con otras soluciones de Capa 2. 

Esto se refleja en sus bajos costos de almacenamiento, soporte multilingüe y compatibilidad total de las versiones de análisis y ejecución. permitiendo que los contratos de implementación interactúen sin problemas, como ejecutar múltiples sistemas operativos virtuales en el mismo equipo informático, lo que resulta en una mayor eficiencia de ejecución y tarifas de procesamiento más bajas.

Proceso de trabajo

Ontology Layer 2 tiene 3 partes principales:

  • Depósito de Ontology para la Capa 2,
  • Retirada (Withdraw) de la Capa 2 para Ontology
  • Transacciones de Layer 2 y garantía de seguridad.

En el centro de negociación de Capa 2, los usuarios pueden realizar transacciones, ejecutar solicitudes de contratos y firmar contratos. 

Esta transacción puede ser la misma que el formato de transacción de la cadena principal de Ontology, o puede ser diferente.

Los recopiladores de transacciones (denominados “Collectors”) son responsables de recopilar las transacciones de capa 2 del usuario. 

Puede haber múltiples recopiladores a lo largo del proceso. Los usuarios también pueden transmitir sus transacciones de capa 2 a múltiples recopiladores.

El recopilador empaqueta periódicamente las transacciones de capa 2 recopiladas y las ejecuta para generar un nuevo estado. 

El recopilador también es responsable de enviar la raíz del nuevo estado a la cadena principal de ontología. Después de ejecutar las transacciones empaquetadas en el bloque de Capa 2, la Raíz del nuevo estado se convierte en el estado del bloque de Capa 2. 

El Challenger es responsable de verificar el estado del bloque de capa 2 enviado por el recopilador a la cadena principal de ontología. Esto requiere que el Challenger sincronice el bloque de capa 2 a través del recopilador para mantener el estado global completo.

La prueba de estado de la cuenta incluye información del estado de la cuenta y su prueba de merkle, que se puede obtener de las consultas del Recopilador y del Desafiador. Solo ellos mantienen un estado global completo.

DEPOSITO DE LAYER 2

1. En primer lugar, el usuario realiza una operación de “Depósito” en la cadena principal de Ontología. El contrato de la cadena principal bloquea los fondos de depósito del usuario y registra el estado de este fondo en la Capa 2. En este punto, el estado es “inédito”.

2. Luego se notifica al cobrador que hay una operación de depósito pendiente en la cadena principal de la ontología. El Recaudador modificará su estado en la Capa 2 de acuerdo con la operación del Depósito. El recopilador luego agrega un depósito para liberar la transacción y lo empaqueta con las transacciones de otros usuarios en el bloque de capa 2. Cuando el estado de bloque de Capa 2 alcanza la cadena principal de Ontología, notificará al sistema que se ha liberado el Depósito.

3. El contrato de la cadena principal ejecuta la operación de liberación del depósito y cambia el estado del fondo de depósito a “liberado”.

RETIRO (Withdraw) DE LAYER 2

1. El usuario construye una transacción “Retirar” de Capa 2 y la envía al Recopilador.

2. El recopilador modifica su estado de acuerdo con Retirar y, al mismo tiempo, empaqueta la transacción de Retirada y otras transacciones de usuario juntas en un bloque de Capa 2. Al enviar el estado de bloque de Capa 2 a la cadena principal de Ontología, se enviará la solicitud de Retiro.

3. El contrato de la cadena principal ejecuta la solicitud de Retiro, registra un registro de fondos y establece el estado en “no liberado”.

4. Después de la confirmación del estado, el usuario envía una solicitud de retiro de fondos.

5. El contrato de la cadena principal ejecuta la solicitud de liberación de Retiro, transfiere fondos a la cuenta objetivo y establece el registro de Retiro en “liberado”.

TRANSACCIONES Y GARANTIA DE SEGURIDAD

  • Transacciones de capa 2

1. El usuario construye una transacción de “Transferencia” de Capa 2 y la envía al Recopilador.

2. El recopilador empaqueta la transacción de transferencia y otras transacciones en un bloque de capa 2, ejecuta las transacciones en el bloque y envía el estado de este bloque de capa 2 a la cadena principal de ontología.

3. Espere la confirmación del estado.

  • Garantía de seguridad

Después de que el Operador envía el estado de bloque de Capa 2 a la cadena principal de Ontología, el Challenger también puede ejecutar la transacción de bloque de Capa 2 y verificar la corrección del Estado de bloque de Capa 2. Si no es correcto, el Challenger recopilará pruebas de fraude y lo presentará al contrato inteligente de Capa 2 para desafiar al Operador.

  • Cómo utilizar

Actualmente, Ontology Layer 2 está disponible en Ontology TestNet para que los desarrolladores lo experimenten.

Enlace: http://152.32.217.204/

Enlace al documento: https://github.com/ontio/layer2

En el próximo artículo, proporcionaremos una comparación detallada del rendimiento con la Capa 2 en otras cadenas.

Apéndice: Explicación de términos

  • Transacciones de Capa 2 (Layer 2)

El usuario ha solicitado transferir o ejecutar un contrato en la Capa 2 y ya lo ha firmado. Esta transacción puede ser la misma que el formato de transacción de la cadena principal de Ontology, o puede ser diferente.

  • Recopilador (Collector)

El recopilador es un recopilador de transacciones de capa 2. Es responsable de recopilar las transacciones de Capa 2 del usuario, verificar y ejecutar la transacción. Cada vez que se genera un bloque de capa 2, el recopilador es responsable de ejecutar las transacciones en el bloque, actualizar el estado y generar contratos de capa 2 que pueden interpretarse como prueba del estado utilizado para garantizar la seguridad.

  • Layer 2 Block

El recopilador empaqueta periódicamente las transacciones de capa 2 recopiladas, genera un bloque que contiene todas las transacciones de capa 2 y genera un nuevo bloque de capa 2.

  • Layer 2 State

El recopilador ejecuta las transacciones empaquetadas en el bloque de capa 2, actualiza el estado, ordena todos los datos de estado actualizados para generar un árbol Merkle y calcula el hash raíz del árbol Merkle. El hash raíz es el estado de la capa 2 del bloque.

  • Operador

El Operador es el “security daemon of Layer 2” y es responsable de monitorizar si hay una transferencia de token a la Capa 2 o una transacción de transferencia de token de la Capa 2 a la cadena principal de Ontology. 

El Operador también es responsable de enviar periódicamente la prueba de estado de la Capa 2. Puede ir a la red principal de Ontología como prueba.

  • Challenger

El Challenger es responsable de verificar la prueba de estado presentada por el Operador a la cadena principal de Ontología. 

Esto requiere que el Challenger sincronice las transacciones de Capa 2 del Operador o la cadena para mantener el estado global completo. 

Después de que el Challenger ejecuta sincrónicamente la transacción y actualiza el estado, puede verificar la exactitud de la prueba de estado presentada por el Operador en la red principal. 

Si no es correcto, el Challenger puede generar un desafío a prueba de fraude que el contrato de Capa 2 puede explicar.

  • Prueba del estado de la cuenta

Logrado a través de la prueba de Merkle, se puede obtener la prueba del estado de la cuenta de Operadores y Desafiadores. Son las únicas partes que mantienen un estado global completo.

  • Prueba de fraude

La prueba de fraude incluye la prueba del estado de la cuenta antes de la actualización actual del bloque de capa 2.

El certificado de estado de bloque de capa 2 anterior y el certificado de estado de cuenta enviado demuestran la legitimidad del estado anterior antes de la actualización. La prueba de que el estado anterior es legal puede lograrse ejecutando el bloque actual.

La cadena de bloques centrada en la empresa de Ontology está lista para ayudar a las empresas a transformar y actualizar sus negocios. Si tiene problemas con la escalabilidad fuera de la cadena, las máquinas virtuales o un conjunto completo de sistemas técnicos, contáctenos a través de contact@ont.io.


Donde encontrar mas información de Ontology

Sitio web de Ontology / Ontology GitHub / Sitio web de ONTO / OWallet (GitHub)

Telegram (Inglés) / Discord

Twitter / Reddit / Facebook / LinkedIn


Dejar respuesta

Please enter your comment!
Please enter your name here