Bien!!! Han atendido a uno de los puntos que siempre critiqué!
(el menos importante, pero bueh ... algo es algo)
Básicamente han cambiado el formato JSON para los metadatos por un formato más eficiente. Yo siempre propuse Protobuf para eso, pero aparentemente el formato se llama CBOR.
Consiste simplemente en separar los valores con dos puntos. Un ejemplo de un mint de la página
cybord.org:
cbrc-20:mint:BORD=1000
Esto reemplaza a algo así en BRC-20:
{
"p": "brc-20",
"op": "mint",
"tick": "ВORD",
"amt": "1000"
}
y así al menos una de las mayores atrocidades cometidas por Domodata (usar un archivo JSON, es decir que había que almacenar hasta las comillas!) se ha resuelto.
Igual el protocolo sigue siendo malo. Usar una inscripción que requiere dos transacciones para una sola transferencia de tokens no tiene sentido. Y eso lo que dice este "experto en Ordinals" es probablemente mentira:
En general, estimo que esto da como resultado tarifas ~60% más bajas para CBRC que para BRC.
FuentePorque los 60-70% de ahorro solo se refieren al
contenido de la inscripción. No se tocan las firmas digitales y otras partes de las entradas y salidas (inputs y outputs) de la transacción. El contenido de una inscripción BRC-20, como escribí en el último post, pesa unos 50-60 bytes, pero las dos transacciones juntas en general pesan no menos de 300 (dependiendo de la cantidad de entradas y salidas). Por ejemplo, una
transacción reciente BRC-20 fue de 320 bytes, a lo que hay que sumarle los bytes de la transacción anterior (la "commitment transaction"). En este caso tenemos un usuario que "la hizo bien" y generó 11 transacciones BRC-20 con una sola "commitment transaction", es decir que usó solo 60 bytes por BRC-20. En total, entonces, usó aproximadamente 380 bytes por BRC-20.
Con CBRC-20 se pueden ahorrar unos 40 bytes por transacción. Es decir en el caso ideal la reducción del peso y por ende de las comisiones es de unos 15%, y en casi todos los casos es menos. Pero bueno, algo es algo.
