Guía Cocos-BCX (COCOS) Token ¿Cómo funciona y cómo comprar?

Características

Expresión de valor único de uso universal

Los activos digitales no homogéneos definidos por el estándar 1808 admiten una variedad de enfoques de escala y personalización de datos. Son compatibles con diferentes tipos de activos en varios juegos y se pueden usar como expresión general para varios datos del juego.

Casos de uso cruzados sin que se afecten entre sí (muro mundial)

El área de datos extendida se combina en la unidad de zona. Cada zona está vinculada a uno o varios contratos que solo son responsables de sí misma. Representa un área de datos que es única para el caso de uso (mundo del juego). La información del par clave-valor después de desplegar la zona representa una serie de datos relacionados con el negocio del juego. Los datos entre diferentes zonas se pueden leer pero no escribir entre sí, es decir, los cambios de datos en diferentes casos de uso no se afectan entre sí. El «muro del mundo» del juego evitará que estas propiedades afecten a otros mundos, lo que no dará lugar a la situación de «equipo degradado en el juego A también se degrada en el juego B».

Diseño compatible con cosmovisión

Los activos digitales no homogéneos definidos por el estándar 1808 permiten que los activos digitales bajo la misma visión del mundo se utilicen en diferentes escenarios comerciales. Por lo tanto, se requieren ciertas reglas para equilibrar el valor del activo (valor de capacidad) entre diferentes entidades comerciales.

En cuanto al estándar 1808, cuando se hace referencia a una instancia de activo en un nuevo escenario empresarial, se determina un atributo relativo, que toma como referencia algunos datos de otra zona, lo que representa el valor básico del activo. Los datos se pueden identificar en otras entidades comerciales bajo la misma cosmovisión. Cuando la instancia de activo ingresa a diferentes entidades comerciales, el valor en la entidad comercial se determina de acuerdo con este atributo, y otros atributos, como las habilidades del equipo, se complementan con el formulario de datos de zona de la entidad comercial.

Diseño compatible entre redes y estándares cruzados

Los activos digitales definidos en este estándar están diseñados para ser compatibles con otros estándares de activos digitales no homogéneos de red, incluidos ERC-721, ERC-1155, ERC-998, etc. Para un solo tipo de activo digital no homogéneo definido por contratos ( ERC-721, etc.), la instancia de activo puede ser compatible al definir un tipo de activo con la misma estructura de datos personalizada. Para los tipos de activos anidados / combinados definidos por contratos (ERC-998, etc.), la compatibilidad se puede lograr agregando datos de relación de cartera al área de datos extendida.

Los propietarios de activos pueden descartar datos de zonas específicas

Los datos de zona del activo digital estándar 1808 se dejarán con un registro del juego a medida que aumente el número de juegos experimentados. Cuando el propietario ya no necesita los datos generados en un juego determinado debido a errores de refuerzo de los accesorios, se le otorgan atributos negativos o desea volver a desafiar el juego, etc., el propietario puede optar por eliminar los datos de la zona correspondientes al juego, lo que permite los activos para volver a entrar en el juego en el estado inicial.

El control del propietario del activo sobre los datos de la zona del activo se limita a la eliminación completa de los datos de la zona especificada, en lugar del cambio de los datos de la zona para evitar que el propietario haga trampa. Además, la eliminación de los datos de la zona también puede evitar eficazmente que los contratos maliciosos escriban grandes cantidades de datos basura en activos específicos, lo que da como resultado una redundancia de datos.

Activos utilizados como módulo integrado o combinado en la cadena de bloques

Los accesorios y el equipo del juego pueden estar compuestos por varios componentes y elementos. Por lo tanto, los activos digitales no homogéneos de los juegos blockchain también deberían poder anidarse y contener. En este caso, cada activo no homogéneo puede estar compuesto por múltiples activos no homogéneos. El activo principal puede contener uno o más activos secundarios, y los activos secundarios pueden contener además otros activos secundarios.

Para escenarios de juegos con construcción o combinación de equipos, el estándar 1808 proporciona un diseño que admite carteras de activos. Los datos extendidos contienen la zona que registra la relación de combinación. Los datos de la zona registran la información de la relación anidada cuando se combina el activo. Antes de que finalice la relación, no se podrá transferir la propiedad de los activos secundarios anidados.

Comparación de activos no homogéneos

En la actualidad, ERC-721 、 ERC-1155 y ERC-998 de la red Ethereum son los estándares populares de activos digitales no homogéneos, que se utilizan en diferentes escenarios y para diferentes necesidades en la red Ethereum:

ERC-721 Es un estándar de activos digitales no homogéneo aceptado oficialmente definido por contratos inteligentes en la red Ethereum. Tiene una zona de datos personalizable, que permite digitalizar elementos o registros. Las aplicaciones típicas son: Crypto Kitties, Crypto Celebridades, etc.

ERC-1155 Es una interfaz estándar propuesta por Enjin para definir múltiples activos no homogéneos en el contrato inteligente único de Ethereum, que sirve principalmente a los accesorios virtuales en los juegos blockchain. Aplicación típica: War of Crypto.

ERC-998 Es una combinación de tokens no homólogos (CNFT, NFT componibles) definidos en los contratos inteligentes de Ethereum propuestos por Matt Lockyer.

La figura muestra la comparación de los tres estándares de activos no homogéneos anteriores con NHAS-1808, que compara brevemente los elementos esenciales que pueden estar involucrados en blockchain y juegos. Las diferencias marcadas en rojo son las características del estándar 1808 diseñado por COCOS-BCX para el juego en cadena. Estas características están relacionadas con el diseño de la estructura de datos del activo estándar 1808 además de las características de la propia red de la cadena BCX.

Estructura de datos

La estructura de datos de activos digitales no homogéneos en la red blockchain se divide en zona de datos fija y zona de datos escalables.

La zona de datos fijos almacena la información básica de los activos digitales no homogéneos, incluida la identificación del activo, la declaración de la visión del mundo y la zona de datos básicos; Mientras que la zona de datos escalables es una sección funcional diseñada para la extensión de atributos de activos digitales no homogéneos, incluidos los datos de zona y los datos de relación de combinación.

La zona de datos fijos define la identificación del activo, la declaración de la visión del mundo y otros datos básicos. El ID de activo es el identificador único de la instancia de activos en la red de contabilidad distribuida y la credencial única para acceder, verificar y modificar los activos. Declaración de la cosmovisión, incluida la identificación de la cosmovisión, el tipo de juego en el que el activo está vigente y respaldado, el mundo y las monedas que respaldan la circulación de activos en la red. La zona de datos básicos consta además de información que incluye una descripción básica de los activos, tiempo de producción, productor, propietario, usuario, lista en blanco y negro de derechos de uso, etc.

Los datos incluyen la identificación del propietario del activo, la identificación del productor, el tiempo de producción y los atributos básicos del activo (por ejemplo, descripciones del equipo, etc.). La zona de datos escalables almacena diferentes datos comerciales en la cosmovisión respaldada por el activo. Diferentes entidades comerciales tienen ID de zona exclusiva y área de datos en la zona, que está aislada entre sí. Los datos de la zona se almacenan en forma de pares clave-valor de la identidad y los datos de la zona. La zona de datos escalables también contiene una zona de datos para mostrar la relación entre la combinación y el anidamiento de activos, que se utilizan para describir la combinación y afiliación de los activos.

Referencia de estructura de datos

Los tipos de campo y las tablas de referencia de identificación de la zona de datos fijos de los activos digitales no homogéneos definidos en esta norma.

El asset_id_type está diseñado para mantener la unicidad en la red, lo que requiere poco para la longitud del ID. Sin embargo, desde la perspectiva de la compatibilidad de múltiples redes, el tamaño máximo de muestra del ID debe cubrir el número máximo esperado de instancias de activos digitales no homogéneos en la red descentralizada existente basada en cuentas distribuidas. Por ejemplo, si el ID del activo en la red Ethereum es una dirección hash de 40 bytes y el número máximo de muestras que se pueden admitir es 1.462 * 10 ^ 48, direcciones hash u otros enfoques de identificación únicos con un tamaño de muestra mayor que este valor se tiene en cuenta al diseñar el ID de activo en la red a la que se aplica este estándar.

World_view_type contiene la ID de la cosmovisión aplicada al activo y la moneda mundial correspondiente a la cosmovisión, donde la ID de la cosmovisión es un identificador único para la red, y la moneda en circulación es el símbolo único de la moneda (la red que usa el símbolo como una credencial única) o la dirección (la red que utiliza la dirección como credencial única).

El tipo de campos Asset_owner y Asset_creator es account_id_type, que debe tener un tamaño de muestra único y suficiente.

El tipo de campo Asset_create_time es time_point_sec, que se utiliza para identificar la fecha en la que se crea esta instancia de activo. Está determinada por la marca de tiempo del libro mayor cuando se completa la transacción de creación de instancias.

El tipo de campo asset_description es una cadena, que es un dato que se puede utilizar para expresar los atributos básicos de una instancia de activo. Los datos se pueden procesar de una manera personalizada de análisis o cifrado para que coincidan con entidades comerciales específicas y escenarios de aplicación.

 El tipo de campo Mod_data es una lista de ID, que es una tabla de relaciones que consta de una lista de identificadores de ID de activos principales e ID de activos secundarios, que se utilizan para describir la combinación y la relación de anidamiento de activos en diferentes entidades comerciales.

 El tipo de campo World_view es map, que es una tabla de mapeo de pares clave-valor compuesta por identificadores de zona y datos de zona. El identificador de zona es un identificador de tipo de la entidad comercial, correspondiente a uno o varios contratos, y todas las interacciones de datos de la instancia comercial para esta instancia de activo se realizarán en esta zona.

 El tipo de campo Session_key es contract_id_type, que es la identificación de uno o más contratos principales que la empresa debe contener. La identificación debe ser tan única y suficiente como los otros identificadores únicos.

 El tipo de campo session_data es map, que consta de inner_key y inner_value. Los datos específicos de la clave y el valor son definidos por la entidad comercial responsable de esta zona, que puede incluir cadenas estructuradas o encriptadas como sus datos según sus necesidades.

Game World y el sistema de cosmovisión

A diferencia del concepto de la industria del juego tradicional, los juegos blockchain de BCX no son escenarios comerciales completamente independientes. Cada juego de blcokchain puede considerarse un mundo de juego, y se puede considerar que varios mundos de juego con configuraciones básicas similares tienen una visión del mundo común.

El concepto de cosmovisión no es creado por los juegos de blockchain, sino una característica que ya comparten muchos juegos modernos. Por ejemplo, Warcraft, World of Warcraft, Hearthstone y The Legend of Storm comparten una cosmovisión común del universo de Blizzard, en la que una parte considerable de los accesorios, personajes y activos del juego son comunes. Aunque estos activos tienen una explicación diferente sobre atributos, habilidades, etc. específicos en cada juego, el diseño de estos activos se deriva de las reglas básicas comunes.

La cosmovisión de los juegos blockchain es una identidad que distingue entre la configuración de la historia y la configuración de personajes / elementos / reglas y el alcance de la utilidad. Los elementos del juego siguen una especificación unificada en la cosmovisión y se pueden migrar y distribuir en diferentes mundos del juego bajo esta cosmovisión pagando la «tarifa de migración», que es el «viaje» de los accesorios del juego.

Objeto entre mundos «Viajando», Mundo Multiverso y Paralelo

Los elementos del juego son un tipo de activos digitales no homogéneos que se utilizan en los juegos blockchain. El proceso de elementos que “viajan” a través de diferentes mundos es el de aplicar y cambiar un activo digital no homogéneo en diferentes juegos y servicios bajo la misma visión del mundo.

El estándar 1808 hace posible que los juegos en cadena diseñen un universo multiverso / paralelo. Las diferentes visiones del mundo de los juegos también son universos de juegos diferentes, que forman el multiverso de los juegos en cadena. Los elementos del juego en cada universo pueden circular libremente y están escritos con diferentes atributos, habilidades, etc. en diferentes juegos. Estos elementos no se afectan entre sí. Esto es lo que mencionamos como diseño de artículos en el “mundo paralelo”.

Los datos personalizados escalables permiten a los diseñadores de juegos crear activos de juego únicos. Los datos de la zona que no interfieren permiten que los activos del juego reciban nuevas propiedades que son inmunes mientras «viajan» por el mundo y el universo, al tiempo que hacen posible la vinculación de datos entre juegos (como la ganancia / reducción de habilidades). La imagen a continuación es un ejemplo de los recursos del juego en cadena que viajan a través del mundo en línea / mundo paralelo:

De acuerdo con el diseño de la operación del juego, el estándar de activos no homogéneos 1808 respalda el diseño de viajes pagados a través de la línea mundial a través de un tercero específico. Esto es útil para que el funcionamiento del juego satisfaga las necesidades de equilibrio de elementos y control de circulación de activos. Cuenta con las siguientes características:

Gestión de datos en el sistema de cosmovisión

El estándar de activos digitales no homogéneos 1808 se define en la cadena inicialmente y se opera a través de un contrato inteligente. La complicada estructura de datos y el diseño de combinación del estándar 1808 hacen que el diseño de la seguridad de los datos de los activos sea más importante. Por tanto, COCOS-BCX analiza los riesgos y peligros potenciales que pueden ocurrir durante la operación de datos en cadena, y comienza a realizar mejoras.

Activos y datos de contrato almacenados por separado

El almacenamiento de datos por separado puede garantizar que el propietario del activo tenga la propiedad total del activo. Si el contrato y los datos de los activos se almacenan juntos, el contrato específico puede llamar a los activos propiedad del contrato bajo la autoridad del desarrollador del contrato, lo cual es muy inseguro. En COCOS-BCX, los datos de los activos homogéneos y no homogéneos y los contratos inteligentes se almacenan por separado, que es un diseño más seguro para los datos, además de ayudar a reducir el consumo de flujo de datos y mejorar la eficiencia de la cadena de bloques.

Mecanismo de verificación de contratos con autenticación de identidad

Para funciones de contrato que involucran operaciones sensibles, COCOS-BCX permite a los desarrolladores definir mecanismos de ejecución de contratos con autenticación de identidad. Una función de contrato con mecanismo de autenticación solo se ejecutará cuando la persona que llama cumpla con los requisitos, evitando el riesgo de que los piratas informáticos ejecuten maliciosamente una interfaz de contrato específica para operaciones de activos ilegales.

Controle los permisos del contrato por datos de zona

El contrato puede obtener todos los datos de zona en los datos de activos extendidos estándar 1808, pero los cambios en los datos de activos se limitarán a la zona marcada como contrato actual. Es decir, el Juego A puede obtener los datos de atributos del activo en el Juego B, pero los cambios al activo solo se guardarán en la zona A, y el contrato A no puede modificar ningún dato en la zona B.

Modo de gestión de propietario de activos para datos de zona

Los datos de la zona se complementan continuamente con el crecimiento de los juegos. Los datos de zona excesivamente agregados o los datos de zona no válidos agregados por contrato malicioso afectarán la eficiencia de ejecución del negocio, lo que resultará en una redundancia de datos de activos. Para evitar esta situación, el estándar 1808 permite al usuario eliminar una zona específica en los datos de activos extendidos. Sin embargo, esto solo le da al usuario el derecho de eliminar los datos de la zona sin incluir el derecho a cambiar los datos de la zona, en caso de que el usuario haga trampa al cambiar los datos.

Escenas de juegos

Esto es para presentar un ejemplo de los elementos del juego que viajan por el mundo del juego. En este escenario de ejemplo, el servicio de juego autoriza a los elementos del jugador a viajar a su propio mundo de juego con una tarifa. Después de que el jugador pasa los activos requeridos pagando una tarifa, el servicio del juego permitirá que los artículos del jugador ingresen al mundo del juego (sistema de contrato).

El servicio de juego recopila la información requerida de los datos de zona de los elementos del jugador y la envía al contrato. Dado que existe un vínculo con el juego anterior, el desarrollador diseña un vínculo con las habilidades del juego anterior (por ejemplo, los ‘ojos de halcón’ que se muestran en el siguiente código), de modo que los elementos que viajan al mundo del juego puedan equiparse con el atributos de habilidad.

      --Contract function: Initialize game items that travel across the game world
      -- item_id:the ID of the item
      --Project Cocos-BCX
      -- original_skill:Skills in the original game
      -- add_skill:Linked skills added in this game
      -- add_description:Description added in this game’s zone data
      function init_item_from_another_world( item_id, original_skill, add_skill, add_description)
        --Non-empty judgment of information
        assert(original_skill~=nil,'null original skill info')
        assert(add_skill~=nil,'null add skill info')
        assert(add_description!=nil,'null description info')
        local add_skill_value='null'
        --Judge the skill information in the original game to get the skill information linked in the game
        local switch={
          ['eyes of hawk']=function() add_skill_value='{"VIT_UP":25}' end
          ['heart of lion']=function() add_skill_value='{"STR_UP":50}' end
          ['speed of pard']=function() add_skill_value='{"AGI_UP":40}' end
          ['wisdom of dwarf']=function() add_skill_value='{"INT_UP":30}' end
        }
        local res=switch[original_skill]
        if(res)then
          res()
          --Update the linked skill information to the zone data
          nht_describe_change( item_id, add_skill, add_skill_value)
          nht_describe_change( item_id, 'another_world_message', add_description)
        else
          assert(res,'unexpected original game skill type')
        end
      end

Implementación de modelos comerciales complejos

La cadena Cocos-BCX agrega una variedad de OP atómicos y estructuras de datos para permitir posibles nuevos negocios. Con el sistema de contratos, los desarrolladores pueden implementar fácilmente modelos de negocios financieros complejos en la cadena de bloques, como arrendamiento de activos, hipotecas, peones, etc. Estos nuevos modelos comerciales mejorarán en gran medida las deficiencias de la falta de liquidez en el modelo económico del sistema blockchain tradicional para activar aún más los comportamientos del mercado. A continuación se muestra una breve introducción al diseño de estos tres modelos de negocio en BCX.

Alquiler

Diseño de contrato:

• Defina las funciones para el negocio de arrendamiento, como iniciar arrendamientos, transferir derechos de uso, reclamar derechos de uso, consultas de estado de inventario y actualizaciones de inventario.
• Defina un grupo de activos disponibles para arrendamiento, con información como la etiqueta de precio.

Proceso:

• El propietario agrega información de activos para ser alquilados a través de la función de actualización de inventario en el contrato y especifica las reglas de alquiler / cálculo;
• El contrato de arrendamiento se establece después de que el inquilino paga el alquiler a través de la función que inicia el contrato de arrendamiento;
• El contrato define la lista en blanco y negro del derecho de uso de activos transfiriendo la función del derecho de uso y transfiere el derecho de uso al inquilino. Luego, el contrato transfiere el alquiler a la cuenta del propietario, marca el estado del activo de inventario como arrendado y define una tarea cronometrada: llamar a la función de reclamo de derechos de uso al vencimiento; * Cuando expira la tarea cronometrada, se llama a la función de reclamo de derechos de uso del contrato para transferir el uso del activo de nuevo al propietario.

Promesa

Diseño de contrato:

• Definir las funciones del negocio de promesas, como iniciar promesas, transferir propiedad, reclamar derechos de uso, consultar el estado de las garantías y establecer listas respaldadas por promesas;
• Definir una estructura de registro de garantías con información sobre los activos disponibles para pignorar y sobre los activos pignorados.

Proceso:

• El acreedor prendario establece la información de los elementos disponibles para la prenda estableciendo la función de lista de garantías, marcando el precio de la prenda o las reglas de cálculo, etc .;
• El pignorante transfiere la propiedad del activo al pignorante a través de la función que inicia el pignorado, recibe el depósito pagado por el pignorante, actualiza la lista de registros de pignoración y libera una tarea cronometrada: el derecho de uso se transfiere de acuerdo con el estado de redención;
• Cuando expira la tarea cronometrada, si no se cumplen el pago del depósito y otras condiciones, se llama a la función de reclamo del contrato para transferir el derecho de uso del activo a la cuenta del acreedor a través de la función de cambio de derecho de uso.

Empeñar

Diseño de contrato:

• Definir las funciones del negocio de empeños, como iniciar el empeño, transferir el derecho de uso, reclamar la propiedad, consultar el estado del artículo empeñado y establecer una lista de empeños;
• Defina una estructura de registro de empeños con información de los activos disponibles para el empeño e información sobre los activos empeñados.

Proceso:

• Casa de empeño establece la información de los artículos disponibles para el empeño configurando la función de lista de empeño, marcando el precio de empeño o las reglas de cálculo, etc .;
• El prestamista transfiere la propiedad del activo al prestamista a través de la función que inicia el empeño, recibe el depósito pagado por el prestamista, actualiza la lista de registros de empeño y libera una tarea cronometrada. base regular / pagar intereses según lo programado / ambos modos según sea necesario;
• Cuando expira la tarea programada, si no se cumplen las condiciones tales como el pago del depósito, se llama a la función de reclamo de propiedad del contrato para transferir la propiedad del activo a la cuenta del prestamista a través del OP de cambio de propiedad. Si se cumple la condición, el derecho de uso se transfiere al peón o mediante el cambio de derecho de uso OP.

EOS1808

Implementación del estándar 1808 en EOS y documentación relacionada Dirección: https://github.com/Cocos-BCX/EOS-1808

ERC1808

Implementación del estándar 1808 en Ethereum y documentación relacionada Dirección: https://github.com/Cocos-BCX/ERC-1808