Ethereum 2.0 vs Symbol (Parte 5): Tokens fungibles
Cuando hablamos de tokenización en el mundo físico, queremos volver algo tangible en algo intangible. Por ejemplo, una “muestra de agradecimiento” es la forma en que hacemos tangible lo intangible (agradecimiento) ejemplo, con un regalo. Mientras estamos en el mundo digital o virtual, cuando hablamos de tokenización, queremos hacer algo tangible intangible. Por ejemplo, tokenizar USD a USD Tether.

La tokenización es una función importante y más utilizada de blockchain. Permite que los activos se transfieran de una parte a otra sin un intermediario. Hay 2 categorías de tokens, los fungibles y los no fungibles. Los tokens fungibles son como puntos de fidelidad o dinero. Por ejemplo, ambos tenemos un dólar, si los cambiamos, ambos tenemos un dólar. El valor no cambiará. Las fichas no fungibles son como un pasaporte. Digamos que ambos tenemos un pasaporte emitido por el mismo país. Se ven iguales desde el exterior, pero la información que aparece en el interior es diferente. Si intercambiamos los pasaportes, realmente ya no nos representan, ya que cada pasaporte es único.
ERC-20
Los tokens en Ethereum, normalmente, se generan mediante la implementación de un contrato inteligente en la red. Como el contrato inteligente de Ethereum es muy versátil, esto también significa que cualquiera puede implementar un contrato inteligente para crear un token en cualquier formato. Imagínese si no hubiera un formulario estándar mientras solicitamos un pasaporte, todos podrían enviar su información personal en un orden diferente y eso sería un gran dolor de cabeza para los oficiales. Por lo tanto, para una mejor experiencia de usuario, especialmente para entidades como Exchanges, se introduce un estándar: el ERC-20. Es por mucho, el estándar más utilizado. Consulte aquí para obtener una lista de tokens ERC-20.
Un contrato inteligente para ERC-20 se llama contrato simbólico. Hay 6 funciones obligatorias en un contrato de token ERC-20 y 3 opcionales (elementos 7 a 9).
- totalSupply (): indica cuántos tokens hay en circulación. Esta es la única función que debe tener valor mientras se implementa el contrato inteligente.
- balance de (dirección): Devuelve el número de tokens que posee la dirección.
- transferencia (dirección, valor): Mueve dicha cantidad de tokens a la dirección mencionada.
- transferFrom (dirección del remitente, dirección del receptor, valor): Mueve dicha cantidad de tokens del remitente al receptor. Útil cuando usa los tokens para pagar servicios, lo que significa que necesita llamar a otro contrato.
- aprobar (dirección del gastador, valor): esto permitió que la dirección de un tercero gastara la cantidad total establecida por el propietario del token.
- asignación (dirección del propietario, dirección del gastador): Devuelva el saldo de las fichas que el gastador todavía puede gastar en nombre del propietario.
- name (): el nombre que desea darle al token. Como no existe un registro central para los contratos de token, no se garantiza la unicidad del nombre.
- símbolo (): una forma más corta de nombre (). P.ej. “Dios mío” para OmiseGO. Normalmente será el ticker. La singularidad no está garantizada.
- decimal (): indica los tokens que se mostrarán. La divisibilidad máxima para Ethereum es 18. Ethereum no se ocupa de decimal. Esto es para fines visuales.
El funcionamiento de cada función se explicará con un ejemplo más adelante.
Hay 2 eventos relacionados con contratos de token.
- Transferencia (dirección del remitente, dirección del receptor, valor): este evento desencadena la transferencia de tokens de una dirección a otra. Si la dirección de destino es una dirección de contrato, activa los códigos en el contrato.
- Aprobar (dirección del propietario, dirección del gastador, valor): este evento se convoca para permitir que un tercero mueva fondos en nombre del propietario, generalmente un contrato de servicio. También especifica la cantidad total permitida. Si el propietario de los tokens envía algunas llamadas a la misma dirección de gasto, reemplaza a la anterior.
Ahora que hemos analizado las funciones y los eventos relacionados con un contrato de token, comencemos con un ejemplo con fines ilustrativos.
Dice que le gustaría crear un token que represente un boleto para un concierto. Empiece por preparar el contrato inteligente. Lo nombra () “concertTicket” con el símbolo () “CTC”. Como no tiene sentido dividir un boleto, el decimal () será “0”. Todas estas funciones son opcionales, pero debe indicar el valor de totalSupplyl (). Si planea vender 1,000 boletos, establezca el valor en 1000. El resto de funciones deben estar ahí para cumplir con el estándar ERC-20.
Luego, implementa el contrato inteligente del token enviándolo a la dirección “0x0”. De hecho, en realidad no crea los tokens, crea los libros de contabilidad / contrato / mapas que registran la propiedad y la transferencia de propiedad de los tokens. Permítanme explicar esto junto con otras preguntas sobre el resto de funciones. En el camino, podría haber otras características que podrían incorporarse, pero no se incluirán en la discusión para mantener esta pieza simple. Blockchain es un agujero de conejo

Una vez que se haya implementado el contrato de token “CTC”, ahora puede comenzar a vender la entrada del concierto. Digamos que Alice te compró un boleto y quieres enviarle un boleto. Llamas a la función de transferencia (dirección de Alice, 1 ticket). Este evento activará la transferencia del evento (su dirección, la dirección de Alice, 1 boleto) y cambiará el saldo de boletos de su propiedad (de 1,000 a 999) y Alice (de 0 a 1).

Dice que también designa a un distribuidor para que venda 100 boletos en su nombre, y debe autorizar al distribuidor a transferir los boletos en su nombre. Deberá llamar para aprobar (dirección del distribuidor, 100 boletos). Se activará el evento Approve (su dirección, dirección del distribuidor, 100 entradas) y cambiará el saldo de la asignación que el distribuidor puede vender a 100 entradas. Tenga en cuenta que esto no cambia el saldo del CTC en su dirección.

Cuando el distribuidor vende un boleto a Bob, el distribuidor llamará a la función transferFrom (su dirección, la dirección de Bob, 1 boleto). Esto cambia el saldo del boleto de su dirección a 998, el de Bob a 1 y la asignación del distribuidor a 99.


Cuando desee verificar el token que posee una dirección, llame a la función balanceOf (dirección). Cuando se desea conocer el saldo de los tokens que se permite mover por un tercero, se llama asignación (dirección del propietario, dirección del gastador).
Con esto, hemos cubierto todas las funciones y los eventos relacionados con un contrato de token. Es posible que haya notado que todas las acciones en relación con la transferencia de propiedad del token de la entrada del concierto de CTC ocurren solo dentro del contrato del token en sí.
Hay 2 tipos de cuentas en Ethereum. Ambas cuentas son:
- representadas con una dirección que comienza con 0x,
- puede recibir, enviar y retener tanto ETH como tokens, y
- puede interactuar con contratos inteligentes implementados.
- Cuenta de propiedad externa (EOA): Es una cuenta de propiedad de un usuario y no cuesta ninguna tarifa de transacción para crearla. Se compone de un par de claves públicas y privadas. Puede iniciar una transacción.
- Cuenta de contrato: se crea mediante la implementación de un contrato inteligente. Por lo tanto, requiere tarifas de transacción ya que utiliza almacenamiento de red. No tiene clave privada, por lo que no puede firmar una transacción. La propiedad de los tokens puede cambiar de manos solo al recibir una transacción que activa el código.
Hay algunos problemas conocidos con ERC-20 que requieren precaución adicional. Primero, el problema de manejo de eventos. El receptor no será notificado de las transacciones entrantes ni podrá rechazar ninguna transacción válida. Esto no es un problema si se envía a la dirección correcta. Aquí, no estoy hablando de que A quiera enviar tokens a B, pero lo envió accidentalmente a C. Estoy hablando de A tenía la intención de enviarlo a otro EOA pero lo envió accidentalmente a una cuenta de contrato. Para empeorar las cosas, si la cuenta del contrato a la que lo envió no maneja los tokens que envió, permanecerá en el limbo.
En segundo lugar, problema de la aprobación () . Como se mencionó al presentar las funciones del contrato de token, el más nuevo aprobado () reemplaza al anterior. Si el gastador nota un cambio entrante en la asignación aprobada y retira la asignación anterior y retira nuevamente cuando entre la nueva aprobación ()
Se proponen soluciones para estos problemas, como ERC-223, que resolverá el primer problema. Aunque es compatible con versiones anteriores, no se usa comúnmente. Ethereum es muy versátil, puede haber funciones escritas para contrarrestar esos problemas. Los procesos de pensamiento y las pruebas cuidadosas y exhaustivas son cruciales.
Nota : ETH no es un ERC-20, ya que se creó antes de que se estableciera el estándar. Otros temas relacionados con ERC-20 y cómo ERC-223 los resuelve se discutirán en otros artículos.
Mosaico
el token fungible de Symbol, el Mosaico, es uno de los complementos. Los estándares del Mosaico se establecieron antes del lanzamiento de la plataforma. El token nativo de Symbol, XYM, en sí mismo es un mosaico. Consulte la parte 3 sobre complementos.
Un mosaico tiene 6 propiedades configurables.
- Suministro inicial: el número inicial de mosaico que se creará en principio. El número máximo de un mosaico es de 9 mil millones.
- Divisibilidad: esto indica qué tan divisible es el mosaico. La divisibilidad máxima de un Mosaico es de 6.
- Duración: el mosaico caducará una vez que finalice la duración. Si desea crear un mosaico que no caduque, establezca esta propiedad en cero. De lo contrario, el máximo de días que puede vivir un mosaico es de 3650 días. No es renovable después de vencido.
- Supply mutable: este es un campo booleano. Cuando se establece en “verdadero”, el suministro total del mosaico puede modificarse, bajo reglas estrictas. Solo el creador puede alterar el suministro total del Mosaico.
- Transferible: este es un campo booleano. Cuando se establece en “verdadero”, el mosaico se puede intercambiar libremente entre cualquier cuenta. De lo contrario, el creador puede transferirlo a cualquier cuenta, pero solo podrá volver a transferirlo al creador. No a ninguna otra cuenta.
- Restringible: este es un campo booleano. Cuando se establece en “verdadero”, se pueden establecer reglas más avanzadas en el mosaico. Esto implicará otro complemento: la restricción de mosaico.
Symbol no se rige por el concepto de contrato inteligente, sino que utiliza complementos, como se discutió anteriormente. Para crear el Mosaico, debe llamar a las transacciones relacionadas: MosaicDefinitionTransaction y MosaicSupplyChangeTransaction. Para facilitar el desarrollo con las 6 propiedades proporcionadas, los SDK disponibles se encargarán del resto de la ejecución.
Tomemos el mismo ejemplo que usamos anteriormente. Establecerás el suministro inicial en 1,000 para representar las entradas para el concierto; establezca la divisibilidad en cero; establezca la duración en 2 meses inmediatamente después del concierto, ya que no desea que las entradas no utilizadas estén disponibles; establezca la mutabilidad de suministro en “falso” ya que no tiene la intención de cambiar el número de asientos; establezca “falso” para que los boletos no sean transferibles, ya que no desea que el comprador revenda el boleto por un precio más alto; y establece “verdadero” para hacer que el mosaico sea restringible.
Se paga una tarifa única a una cuenta sink al crear el Mosaico, además de la tarifa de transacción. Y habrás notado que no mencioné el nombre del Mosaico. En Symbol, un mosaico se representa mediante un entero sin signo de 64 bits. Para nombrar el mosaico, está involucrado otro complemento llamado Espacio de nombres, y hablaremos de él en otra ocasión. Por ahora, solo tenga en cuenta que es posible hacer que el mosaico sea más reconocible.
En Symbol, hay 2 tipos de cuentas:
1.Cuenta: Es un par de claves públicas y privadas. Es un lugar para guardar todos los mosaicos. En Symbol, los saldos de los mosaicos propiedad de cada cuenta se registran en el estado de la cuenta.
2.Cuenta multifirma: convertida de una cuenta. Después de la conversión, ya no puede iniciar ninguna transacción. Todavía puede hacer cualquier cosa como lo puede hacer una cuenta normal. Puede contener mosaicos y enviar transacciones, pero las transacciones deben ser iniciadas por las cuentas que tienen el custodio. Puede imaginarlo como una cuenta bancaria a nombre compartido.
Ahora puedes empezar a vender el billete. Alice quiere comprar un boleto. Ella te paga XYM (moneda nativa del Symbol) y le envías un boleto. Ambos deben llamar a un complemento TransferTransacation para que se realice el intercambio. Ahora, usted tendrá 999 boletos y Alice tendrá uno. También puede hacer que el intercambio se realice automáticamente utilizando el complemento Aggregate Transaction.

No puede designar un distribuidor para transferir los boletos de su cuenta ya que ha establecido la propiedad “transferible” del billete en “falso”. Por lo tanto, el boleto solo se podrá transferir una vez al comprador y el comprador le devolverá el boleto el día del concierto. Sin embargo, puede cambiar la cuenta que creó los boletos a una Cuenta Multifirma y agregar al distribuidor para que tenga la custodia compartida sobre ella. Puede tener la aplicación de venta de entradas para crear transacciones para enviar el 10% de comisión al distribuidor y el 90% a su cuenta cuando el comprador realiza el pago. Dice que ahora el distribuidor le vende un boleto a Bob, él hace un pago, el 90% a usted y el 10% al distribuidor. Posteriormente, usted y el distribuidor firman una transacción para enviar un boleto a Bob desde la cuenta Multisig. Todos estos pueden ser uno como si estuvieran en una transacción utilizando Aggregate Transaction.
Dice que es un concierto de Lady Gaga y que solo habrá un espectáculo. Definitivamente 1,000 boletos no son suficientes para todos. Entonces, decidió venderlos solo para los miembros de su club de fans. Dado que ha establecido la propiedad “Restrictable” en “true”, podrá agregar funciones avanzadas para manejar esto.
Hay 2 partes para configurar. Primero, restringir los mosaicos de tickets para que sean transferibles a cuentas que están etiquetadas. En segundo lugar, la cuenta de los fans deberá ser etiquetada por quien esté manejando el proceso KYC (conozca a su cliente). Con estos configurados, la cuenta de no fan no podrá recibir el ticket Mosaico.
Hasta aquí, hemos analizado las características y comportamientos de Mosaico.
Una mirada más cercana a las diferencias
- El estándar de creación de un mosaico está preestablecido y debe cumplirse. Todos los mosaicos son transferibles a cualquier cuenta, excepto si no son transferibles o tienen restricciones. Aun así, la transacción fallará y ningún Mosaico quedará atrapado en el limbo. La única forma en que un mosaico se considerará perdido para siempre es si la cuenta que contiene los mosaicos perdió su clave privada. Este problema se aplica a todas las cadenas de bloques.
- Solo hay una forma de transferir un Mosaico, que es a través de Transacción de transferencia. Incluso si se usa la Transacción agregada, la Transacción de transferencia todavía está distorsionada dentro de la Transacción agregada.
En conclusión, tanto ERC-20 como Mosaico son flexibles. No son un modelo de avión que cada pieza tiene que ir en su lugar exacto para terminar el modelo. Aparte de un esqueleto que necesita para seguir la estructura, puede usar su imaginación para construir todo tipo de aplicaciones.
Si bien el contrato inteligente de Ethereum es como Play-Doh, los complementos de Symbol son como Lego.
– Ethereum 2.0 vs Symbol (Parte 3)
Como sabemos, Ethereum es muy versátil. Literalmente, puede hacer que la dApp se comporte de cualquier manera. Solo necesita asegurarse de que esté bien probado para defenderse de cualquier acto malicioso.
Si necesita el token para ejecutar reglas complicadas, Ethereum es una buena opción. Si necesita tokenizar sus activos para facilitar el seguimiento y la transferencia, Symbol’s Mosaic es un claro ganador por su simplicidad y su sistema bien probado.
Saber que un cuchillo puede cortar es un conocimiento básico. Saber cómo usar un cuchillo a tu favor es poder. No necesitas un machete para untar tu mantequilla.
Un agradecimiento especial a Anthony por revisar este artículo.
Esta es una traducción al español del artículo original (en inglés) escrito por Ivy Fung en Medium . Traducido y editado por NEM en Español. Juntos estamos haciendo que NEM sea más fuerte y que Symbol sea más brillante.
Para más información y noticias sobre NEM, le invitamos a seguirnos en nuestras redes sociales: Facebook, Twitter e Instagram