Renuncia- Disclaimer - dagcoinlatam.orgdagcoinlatam.org/onewebmedia/Archivos/Dagcoin... · Otro...
68
Transcript of Renuncia- Disclaimer - dagcoinlatam.orgdagcoinlatam.org/onewebmedia/Archivos/Dagcoin... · Otro...
Renuncia- Disclaimer
El presente documento técnico de DAGCOIN es solo para fines informativos DAGCOIN LTD no garantiza
la exactitud o las conclusiones alcanzadas en este documento, y este documento se proporciona
"como es". DAGCOIN OÜ no realiza y renuncia expresamente a todas las representaciones y garantías,
expreso, implícito, estatutario o de cualquier otro tipo, incluidos, entre otros: (i) garantías
de comerciabilidad, idoneidad para un propósito particular, idoneidad, uso, título o no infracción; (ii)
que el contenido de este libro blanco no contiene errores;
Dagcoin OÜ y sus filiales no tendrán responsabilidad por los daños y perjuicios de ningún tipo que surjan del
uso, referencia
o confiar en este documento o en el contenido aquí incluido, incluso si se lo
la posibilidad de tales daños. En ningún caso Dagcoin OÜ o sus filiales serán responsables ante ninguna
persona o
entidad por los daños, pérdidas, responsabilidades, costos o gastos de cualquier tipo, ya sean directos o
indirectos,
consecuente, compensatorio, incidental, real, ejemplar, punitivo o especial para el uso de, referencia
o confiar en este documento o en cualquier contenido incluido en este documento, incluidos, sin
limitación, cualquier pérdida de negocios, ingresos, ganancias, datos, uso, buena voluntad u otras pérdidas
intangibles.
Abstracto Abstract
Hay más de 1700 diferentes criptomonedas disponibles en todo el mundo. La mayoría de ellos son
basado en la tecnología blockchain, que se inventó en 2009. Cuando Bitcoin apareció por primera vez.
Blockchain
La tecnología ha estado pasando por muchas mejoras, como la prueba de juego en lugar de la prueba
de trabajo, muchos algoritmos de minería diferentes están en uso y la última mejora, segwit, se inició con
litecoin y otras monedas. Todavía hay algunos problemas importantes con respecto a la tecnología
blockchain.
El primer problema con respecto a blockchain es la escalabilidad. En una escala mayor: escuchar
transacciones, ponerlas
en los bloques y tratando de obtener confirmación y consenso sobre los bloques, solo lleva tiempo. Eso
no importa mucho, ya sea POW o POS, incluso en comparación con algunas plataformas de transacciones
centralizadas,
tales diseños de blockchain son demasiado lentos.
Otro problema es el costo de la prueba de trabajo. Hoy, la transacción de bitcoin, que inicialmente se hizo
para
reducir el costo de las transacciones de dinero, es una de las transacciones más caras en el
mundo. PRISIONERO DE GUERRA no es manera eficaz de energía para asegurar libros mayores.
El tercer problema es el hecho de que la comunidad de criptomonedas ha sido reconocida de alguna manera,
La mayoría de los mineros tienen la clave de la palabra final para las nuevas mejoras y mejoras
dentro de la red Los mineros son como un grupo de interés separado, con sus propios incentivos económicos,
además de ser los inductores que están realizando transacciones dentro de la red. Ese ha sido el bloqueador
para introducir nuevas características en bitcoin blockchain. Por ejemplo, la activación de segwit y etherum
blockchain moviéndose de POW a POS.
1. INTRODUCCIÓN
Dagcoin es una criptomoneda descentralizada que se utiliza ampliamente en mercados asiáticos
pero se puede usar en todo el mundo.
Dagcoin se construyó sobre la red de byteball. Byteball fue presentado por primera vez por Anton
Churyumov
en 2015 y ha estado en vivo desde septiembre de 2016. Los datos de Byteball se almacenan y ordenan
usando
gráfico acíclico (DAG) en lugar de blockchain. Esto permite que todos los usuarios se aseguren las
transacciones de los demás
al hacer referencia a transacciones anteriores creadas por otros usuarios, y también elimina los límites de
escalabilidad
común para blockchains, como el problema blocksize.
El algoritmo de consenso utilizado para proteger contra el doble gasto se basa en establecer un orden total
dentro del DAG. Esto se logra seleccionando una cadena, llamada cadena principal, que gravita hacia
unidades emitidas por usuarios acreditados comúnmente reconocidos: testigos. Vea el libro blanco de
Byteball para
detalles.
Dagcoin está utilizando byteball como red subyacente, pero es un activo totalmente nuevo. Todos juntos
tienen
ha emitido 1 000 000 000 Dags, lo que significa 10 * 15 microDags. Dagcoin tendrá las mismas
funcionalidades
como Byteball: chatbot, pagos condicionales, cambio descentralizado, pagos P2P, etc.
Al usar Dag-chain, Dagcoin es la primera criptomoneda que apunta a mercados en desarrollo con el
capacidad de ser una moneda cotidiana. Habiendo resuelto los problemas de escalabilidad y manteniendo el
costo
de las tarifas de transacción muy bajas, el único desafío es difundir el conocimiento sobre las criptomonedas
y Dagcoin. Para esto, se realizarán extensas campañas de marketing en las redes sociales y también en las
tradicionales
canales de comercialización junto con el marketing de afiliación.
Es importante educar al usuario final sobre qué es la criptomoneda y cuáles son los beneficios de usar
eso.
2 DAGCHAIN
2.1 ¿QUÉ ES BLOCKCHAIN?
La mayoría de las criptomonedas se basan en la tecnología innovadora blockchain.
Un blockchain es un libro público de todas las transacciones que alguna vez se han ejecutado. Está en
constante crecimiento
a medida que se agregan bloques 'completados' con un nuevo conjunto de grabaciones. Los bloques se
agregan a la
blockchain en orden lineal y cronológico.
Para usar la banca convencional como una analogía, el blockchain es como un historial completo de
transacciones bancarias.
Las transacciones se ingresan cronológicamente en una cadena de bloques del mismo modo que las
transacciones bancarias.
Los bloques, mientras tanto, son como estados de cuenta bancarios individuales.
2.2 DESAFÍOS DE LA BLOQUE DE BLOQUEO:
2.2.1 Transacciones por segundo
El tamaño cada vez mayor de la cadena de bloques es un problema para el almacenamiento y la
sincronización. Red Bitcoin
puede procesar 7 transacciones por segundo y las cadenas de bloques más capaces podrían teóricamente
procesar unas miles de transacciones por segundo. VISA es la red de pagos más grande que puede
de procesar 56 000 transacciones por segundo. Como la criptomoneda debería ayudar a los no bancarizados,
la necesidad
para las transacciones es mucho más alto de lo que VISA puede manejar.
2.2.2 Comisiones de transacción
Las tarifas de transacción aumentan con el aumento de las transacciones. Los usuarios pueden pagar tarifas
más grandes a los mineros para
motívelos para confirmar las transacciones más rápido.
Blockchain es ideal para contratos inteligentes y burocracia corporativa, pero no para la moneda cotidiana.
Bitcoin es perfecto como oro digital, pero no como moneda corriente.
2.3 CADENA DEL DAG
Además de la información de la transacción, una unidad de cadena DAG incluye las firmas de uno o
más usuarios que crearon la unidad y referencias a una o más unidades previas (padres) identificadas por
sus hashes.
Las unidades están vinculadas entre sí de tal manera que cada unidad incluye uno o más hash de unidades
anteriores,
que sirve tanto para confirmar unidades anteriores como para establecer su orden parcial. El conjunto de
enlaces entre
las unidades forman un DAG (gráfico acíclico dirigido). No hay una sola entidad central que administre o
coordine
admisión de nuevas unidades en la base de datos, todos pueden agregar una nueva unidad siempre que
él lo firma y paga una tarifa igual al tamaño de los datos agregados en bytes. La tarifa es cobrada por otros
usuarios
quien luego confirma la unidad recién agregada incluyendo su hash dentro de sus propias unidades. Como
nuevas unidades son
agregado, cada unidad anterior recibe más y más confirmaciones por unidades posteriores que incluyen su
hash,
directa o indirectamente.
A diferencia de las blockchains donde emitir un bloque es un evento raro y solo una casta privilegiada de
usuarios es en la práctica
En esta actividad, una nueva unidad comienza a acumular confirmaciones inmediatamente después de su
lanzamiento
y las confirmaciones pueden provenir de cualquier persona, cada vez que se emita otra unidad nueva. No hay
sistema de dos niveles de usuarios comunes y mineros. En cambio, los usuarios se ayudan mutuamente: al
agregar una nueva unidad se
autor también confirma todas las unidades anteriores.
Las referencias a los padres es lo que establece el orden (solo el orden parcial hasta el momento) de las
unidades y generaliza
la estructura de blockchain. Dado que no estamos confinados a las relaciones de un padre y un hijo entre
bloques consecutivos, no tenemos que esforzarnos por una sincronía cercana y podemos tolerar de manera
segura grandes latencias
y altos rendimientos.
2.4 PRIMEROS USOS DE DAG CHAIN
2.4.1 Draft
En 2015, Sergio Demian Lerner, especialista en criptomonedas de Argentina, publicó su borrador
(redactado ya en 2012) de una moneda basada en la cadena DAG, a la que llamó Dagcoin. Esto nunca se
convirtió
un proyecto y se mantuvo como un borrador, por lo que no se creó ninguna moneda real.
2.4.2 IOTA
A finales de 2015, un cryptotoken optimizado para la industria del Internet de las cosas (IoT) llamado IOTA,
era
introducido. En lugar de la cadena de bloques global, la principal innovación detrás de IOTA es un DAG que
llaman
Enredo: un libro de contabilidad distribuido sin bloques que es escalable y liviano. IOTA se encuentra
actualmente en Beta.
2.4.3 Byteball
Byteball se introdujo a mediados de 2016. Byteball es un sistema descentralizado que permite manipular
almacenamiento a prueba de datos arbitrarios, incluidos los datos que representan valores transferibles,
como las monedas,
títulos de propiedad, deuda, acciones, etc. Hay una moneda interna llamada 'bytes' que se usa para pagar
agregar datos a la base de datos descentralizada. Otras monedas (activos) también pueden ser emitidas
libremente por
cualquier persona para representar los derechos de propiedad, deuda, acciones, etc. Los usuarios pueden
enviar tanto bytes como otras monedas
unos a otros para pagar bienes / servicios o cambiar una moneda por otra.
2.4.4 Dagcoin
Dagcoin es el primer activo creado en la plataforma y red de Byteball, aparte de la moneda interna de
Byteball.
bytes. Dagcoin y Byteball evolucionan de la mano: Dagcoin se beneficia de los desarrollos de
Byteball y viceversa. La popularidad de cualquiera de los dos mejora el efecto de red para el otro.
3 BYTEBALL
Byteball es un sistema descentralizado que permite el almacenamiento a prueba de manipulaciones de datos
arbitrarios, incluidos los datos
que representa el valor transferible, como monedas, títulos de propiedad, deuda, acciones, etc. Unidades de
almacenamiento
están vinculados entre sí de manera que cada unidad de almacenamiento incluye uno o más valores hash de
almacenamiento anterior
unidades, que sirven tanto para confirmar unidades anteriores como para establecer su orden parcial. El
conjunto de enlaces
entre las unidades forma un DAG (gráfico acíclico dirigido). No hay una sola entidad central que gestione o
coordina la admisión de nuevas unidades en la base de datos, todos pueden agregar una unidad nueva
provista
que lo firma y paga una tarifa igual al tamaño de los datos agregados en bytes. La tarifa es cobrada por
otros usuarios que luego confirman la unidad recién agregada incluyendo su hash dentro de sus propias
unidades.
Se agregan nuevas unidades, cada unidad anterior recibe más y más confirmaciones por unidades posteriores
que incluyen
su hash, directa o indirectamente. Hay una moneda interna llamada 'bytes' que se usa para pagar
agregar datos a la base de datos descentralizada. Otras monedas (activos) también pueden ser emitidas
libremente por
cualquier persona para representar derechos de propiedad, deuda, acciones, etc.
Los usuarios pueden enviar tanto bytes como otras monedas para pagar bienes / servicios o intercambiar
una moneda por otra, las transacciones que mueven el valor se agregan a la base de datos como
unidades de almacenamiento.Si dos transacciones intentan gastar el mismo resultado (gasto doble) y no hay
ninguna parcial
orden entre ellos, ambos están permitidos en la base de datos, pero solo el que viene antes en el
el orden total se considera válido.
El orden total se establece al seleccionar una sola cadena en el DAG (la cadena principal) que se siente
atraída por
unidades firmadas por usuarios conocidos llamados testigos. Una unidad cuyo hash está incluido
anteriormente en la cadena principal
se considera antes en el orden total. Los usuarios eligen a los testigos nombrando a los testigos de confianza
del usuario
en cada unidad de almacenamiento.
Los testigos son usuarios de buena reputación con identidades del mundo real, y los usuarios que los nombre
esperan que
nunca intente gastar doblemente. Mientras la mayoría de los testigos se comporten como se espera, todos
los dobles
los intentos se detectan a tiempo y se marcan como tales. Las unidades autoconocidas se acumulan después
una unidad de usuario, existen criterios determinísticos (no probabilísticos) cuando el orden total del usuario
la unidad se considera final.
Los usuarios almacenan sus fondos en direcciones que pueden requerir más de una firma para gastar
(multigias).
El gasto también puede requerir que se cumplan otras condiciones, incluidas las que son evaluadas por
buscando datos específicos publicados en la base de datos por otros usuarios (oráculos).
Los usuarios pueden emitir nuevos activos y definir reglas que rigen su transferibilidad. Las reglas pueden
incluir
restricciones de gastos, tales como un requisito para que cada transferencia sea firmada por el emisor del
activo,
que es una forma de que las instituciones financieras cumplan con las regulaciones existentes.
Los usuarios también pueden emitir activos cuyas transferencias no se publican en la base de datos y, por lo
tanto, no son visibles.
a terceros. En cambio, la información sobre la transferencia se intercambia de forma privada entre los
usuarios,
y solo se publica un hash de la transacción y una prueba de gasto (para evitar el doble gasto)
a la base de datos.
4 DAGCOIN ASSET
4.1 DEFINICIÓN
Dagcoin es un activo definido dentro de byteball, una criptomoneda de gráfico acíclico directo sin bloque. La
ventaja
de aprovechar esa tecnología es que Dags no están minadas y, por lo tanto, todo el proceso de
la validación de transacciones es más ligera y escalable.
Se han definido 1 billón de DAGCOIN. La definición de activo aunque creó realmente 1015 unidades base,
llamado microDags (μDags). Un Dag es equivalente a un millón de μDags.
El activo DAGCOIN se definió con las siguientes especificaciones técnicas:
tapa 1000000000000000
is_private false
is_transferrable true
auto_destroy falso
fixed_denominations false
issued_by_definer_only true
cosigned_by_definer false
spender_attested false
4.2 CODEBASE
El código base de DAGCOIN está compuesto por 3 proyectos distintos: el cliente, un explorador y un
faucet, respectivamente bifurcaciones de los proyectos de byteball correspondientes.
El cliente está disponible para las siguientes plataformas: Windows, Mac, Linux y Android.
Estas horquillas están destinadas a ser versiones más delgadas de byteball, donde las partes de la dagchain
que no son relevantes para el activo DAGCOIN se filtran.
Algunas características adicionales también son necesarias y se desarrollaron específicamente para este
activo, como
grifo.
La característica adicional más importante, aún en desarrollo, apunta a abordar el problema de
transferir el activo de un usuario final a otro sin que tengan que prefinar su billetera
con bytes para cubrir la tarifa que debe pagarse para que las unidades sean validadas y procesadas por
testigos.
5 LA RED DEL CENTRO DE INTERCAMBIO
5.1 SITUACIÓN ACTUAL
Queremos permitir a nuestros usuarios finales transferir DAGCOIN sin tener que lidiar con el subyacente
red byteball.
Esto no es fácil de conseguir, dado que para cualquier transferencia se requiere una nueva unidad de
byteball, cuya
la creación requiere a su vez un gasto de bytes.
Por lo tanto, lo que necesitamos es una forma de proporcionar a nuestros clientes los bytes que necesitan de
forma transparente.
5.2 BUJES DE INTERCAMBIO Y SUS FUNCIONALIDADES
Un centro de intercambio es una entidad disponible en la red DAGOIN (y por lo tanto en el byteball) cuya
responsabilidad
es proporcionar bytes (necesarios para crear nuevas transacciones) a los clientes de DAGCOIN que
necesitar o requerirlos.
Centros de financiación:
• Los hubs funcionan como una oficina de intercambio: proponen intercambiar DAGCOIN por bytes en un
cierto
tarifa
• Trabajan, de forma similar a los testigos, de forma independiente unos de otros de forma que cualquiera
pueda
tiene la posibilidad de convertirse en un centro. Potencialmente, cualquier cliente tiene esta posibilidad.
• Su servicio no puede ser centralizado o controlado por nadie
• Ofrecer tipos de cambio: el cliente puede elegir la mejor oferta.
5.3 SOLUCIÓN DE DIRECCIÓN COMPARTIDA
5.3.1 Supuestos técnicos a verificar
• Es posible compartir una dirección entre carteras
• Es posible para el propietario de la dirección autorizar o denegar transacciones. Si la dirección es
compartida entre muchos clientes, una transacción puede ser denegada o autorizada solo por la dirección
propietario (el centro).
Un centro comparte una dirección ampliamente financiada con los clientes que están interesados en su
servicio. El cliente puede usar
tales se dirigen a un pagador de tarifas para una transacción DAGCOIN previa aprobación del centro que
posee la dirección.
Cada billetera de cliente contendría una dirección por centro a la que está suscrita.
Cuando necesita fondos para crear una nueva transacción, utiliza esta dirección como pagador de tasas.
El hub firmará la transacción.
5.4 SOLUCIÓN DE WALLET COMPARTIDA
5.4.1 Suposiciones técnicas para ser verificado
• Incluso en una billetera compartida, aún es posible mantener direcciones separadas y distinguir entre
los dueños de la billetera compartida
• Un propietario puede guardar sus pertenencias en una dirección dentro de la billetera que nadie más
puede manipular
• Usar fondos de una dirección requiere la autorización del propietario real.
Tras la creación del cliente, se crea una nueva billetera y se comparte con un centro. En esta billetera hay una
dirección
privado para el cliente donde el cliente tiene sus objetos de valor (DAGCOIN) y una dirección compartida
donde el centro tiene algunos fondos (bytes).
En esta imagen se muestra que una solución basada en una billetera compartida crearía en efecto una red de
carteras compartidas entre centros y usuarios finales.
En tales billeteras, la dirección del usuario final sería privada para el usuario final y la dirección compartida
pública
a ambos. Crear una transacción usando fondos (bytes) desde la dirección compartida del concentrador
requeriría la
hub para costear.
5.5 PROTOCOLO DE FINANCIACIÓN DEL HUB
Cualquiera que sea la implementación subyacente (dirección compartida o billetera u otra cosa), la
financiación
protocolo funcionará más o menos de la misma manera
Imagine un escenario donde un cliente desea enviar algunos DAGCOIN a otro cliente sin tener
los bytes requeridos para crear la transacción.
Tenemos los siguientes actores:
1. Cliente A con una dirección privada (#A) donde se almacenan algunos DAGCOIN.
2. Cliente B con una dirección privada (#B) utilizada para intercambios DAGCOIN
3. Intercambie el Hub 1 con una dirección pública (n. ° 1).
El cliente A tiene una única opción: usar un centro de intercambio para alimentar su transacción. A debe
encontrar un centro,
cuya lista puede incluirse posiblemente en el código o a través de un servicio de descubrimiento.
De cada centro A recibe una dirección ricamente dotada de bytes para incluir en su billetera.
1. Cuando A desea enviar algunos DAGCOIN a B, crea una configuración de transacción como dirección de
pago
el que se recibe del centro y le pide al centro una cotización (un tipo de cambio para estimar
el precio final). La tarifa en este punto aún no es definitiva.
2. El centro 1 propone una cotización que el cliente puede aceptar de rechazar (en ese caso debe encontrar
un
centro diferente para proceder)
3. A agrega una salida a la transacción que contiene una transferencia de DAGCOIN a la dirección del
concentrador
equivalente a la cantidad de bytes requeridos por la transacción si se convirtieron utilizando
el centro propuso el tipo de cambio. Entonces lo firma. La tarifa en bytes en este momento es final.
4. El centro verifica que la transacción sea correcta (tamaño, tarifa, tipo de cambio) y, si todo es correcto
como debería ser, lo firma, validando la transacción.
6 EXTRACTOS DE BYTEBALL WHITEPAPER
6.1 ESTRUCTURA DE LA BASE DE DATOS
Cuando un usuario desea agregar datos a la base de datos, crea una nueva unidad de almacenamiento y
lo transmite a sus compañeros. La unidad de almacenamiento incluye (entre otras cosas):
• Los datos que se almacenarán. Una unidad puede incluir más de un paquete de datos
llamó un mensaje. Hay muchos tipos diferentes de mensajes, cada uno con su
estructura propia Uno de los tipos de mensajes es el pago, que se usa para enviar
bytes u otros activos a pares.
• Firma (s) de uno o más usuarios que crearon la unidad. Los usuarios son identificados por sus direcciones.
Los usuarios individuales pueden (y se les alienta) tener varias direcciones, como en
Bitcoin. En el caso más simple, la dirección se deriva de una clave pública, de nuevo similar a Bitcoin.
• Referencias a una o más unidades previas (padres) identificadas por sus valores hash.
Las referencias a los padres es lo que establece el orden (solo el orden parcial hasta el momento) de las
unidades y generaliza
la estructura de blockchain. Dado que no estamos confinados a las relaciones de un padre y un hijo entre
bloques consecutivos, no tenemos que esforzarnos por una sincronía cercana y podemos tolerar de manera
segura grandes latencias
y altos rendimientos: tendremos más padres por unidad y más niños por unidad. Si vamos
reenviar en la historia a lo largo de los enlaces padre-hijo, observaremos muchas bifurcaciones cuando se
hace referencia a la misma unidad
por múltiples unidades posteriores, y muchas se fusionan cuando la misma unidad hace referencia a
múltiples unidades anteriores
(los desarrolladores ya están acostumbrados a ver esto en git). Esta estructura es conocida en la teoría de
grafos como dirigida
gráfico acíclico (DAG). Las unidades son vértices y los enlaces padre-hijo son los bordes del gráfico.
En el caso especial cuando las unidades nuevas llegan con poca frecuencia, el DAG se verá casi como una
cadena, con solo ocasionales
tenedores y fusiones rápidas.
Como en blockchains donde cada bloque nuevo confirma todos los bloques previos (y las transacciones allí),
cada nueva unidad infantil en el DAG confirma a sus padres, todos los padres de los padres, los padres de los
padres,
etc. Si uno intenta editar una unidad, también tendrá que cambiar su hash. Inevitablemente, esto se
rompería
todas las unidades secundarias que hacen referencia a esta unidad por su hash como firmas y hashes de
niños dependen de
hashes de padres. Por lo tanto, es imposible revisar una unidad sin cooperar con todos sus hijos o
robando sus llaves privadas. Los niños, a su vez, no pueden revisar sus unidades sin cooperar con
sus hijos (nietos de la unidad original), y así sucesivamente. Una vez que una unidad se transmite a la red,
y otros usuarios comienzan a construir sus unidades en la parte superior (haciendo referencia a ella como
padre), la cantidad de
revisiones secundarias requeridas para editar esta unidad, por lo tanto, crece como una bola de nieve. Es por
eso que llamamos a este diseño
Byteball (nuestros copos de nieve son bytes de datos).
dieciséis
A diferencia de las blockchains donde emitir un bloque es un evento raro y solo una casta privilegiada de
usuarios es en la práctica
comprometido en esta actividad, en una nueva unidad de Byteball comienza a acumular confirmaciones de
inmediato
después de que se lanza y las confirmaciones pueden venir de cualquier persona, cada vez que se emite otra
unidad nueva.
No hay un sistema de dos niveles de usuarios comunes y mineros. En cambio, los usuarios se ayudan
mutuamente: agregando un
nueva unidad su autor también confirma todas las unidades anteriores.
A diferencia de Bitcoin, donde un intento de revisar una transacción pasada requiere un gran esfuerzo
computacional,
un intento de revisar un registro pasado en Byteball requiere coordinación con un número grande y creciente
de otros usuarios, la mayoría de los cuales son extraños anónimos. La inmutabilidad de los registros
anteriores es por lo tanto
basado en la gran complejidad de coordinar con un número tan grande de extraños, que son difíciles
para llegar, no tienen interés en la cooperación, y donde cada uno de ellos puede vetar la revisión.
Al hacer referencia a sus padres, una unidad incluye al padre. No incluye el contenido completo del padre;
más bien, depende de su información a través del hash de los padres. De la misma manera, la unidad
indirectamente
depende de, y por lo tanto incluye, a los padres del padre, a sus padres, etc., y cada unidad
finalmente incluye la unidad de génesis.
Existe una regla de protocolo que establece que una unidad no puede hacer referencia a padres
redundantes, es decir, padres que
uno de los padres incluye a otro. Por ejemplo, si la unidad B hace referencia a la unidad A, entonces la unidad
C no puede hacer referencia
ambas unidades A y B al mismo tiempo. A ya está, de alguna manera, dentro de B. Esta regla elimina
innecesarios
enlaces que no agregan ninguna nueva conectividad útil al gráfico.
6.2 MONEDA NATIVA: BYTES
A continuación, tenemos que introducir cierta fricción para proteger contra el correo no deseado de la base
de datos con inútil
mensajes. La barrera de entrada debe reflejar aproximadamente la utilidad del almacenamiento para el
usuario y el costo
de almacenamiento para la red. La medida más simple para ambos es el tamaño de la unidad de
almacenamiento.
Por lo tanto, para almacenar sus datos en la base de datos descentralizada global, debe pagar una tarifa en
moneda interna.
llamados bytes, y el monto que paga es igual al tamaño de los datos que va a almacenar (incluido
todos los encabezados, firmas, etc.). Similar a la libra esterlina, que era igual a una libra de plata
cuando se introdujo por primera vez, el nombre de la moneda refleja su valor. Para mantener los incentivos
alineado con los intereses de la red, hay una excepción en las reglas de cálculo de tamaño. Para los fines
de calcular el tamaño de la unidad, se supone que la unidad tiene exactamente dos padres, sin importar el
verdadero
número.
Por lo tanto, el tamaño de dos hash de unidades principales siempre se incluye en el tamaño de la unidad.
Esta excepción
asegura que los usuarios no intenten incluir solo a uno de los padres en un esfuerzo por minimizar el costo. El
costo es el
lo mismo no importa cuántos padres estén incluidos.
Para mantener el DAG lo más estrecho posible, incentivamos a los usuarios a incluir tantos padres como sea
posible
(como se mencionó anteriormente, esto no afecta negativamente el tamaño pagadero), y como padres
recientes como sea posible,
pagando parte de los honorarios de la unidad a quienes primero los incluyan como padres. Definiremos más
tarde
qué es exactamente 'primero'
Los bytes se pueden usar no solo para el pago de tarifas de almacenamiento (también llamadas comisiones),
sino que también pueden ser
enviado a otros usuarios para pagar bienes o servicios o a cambio de otros activos. Para enviar un pago,
el usuario crea una nueva unidad que incluye un mensaje de pago como el siguiente (a partir de ahora,
usa JSON para describir estructuras de datos):
El mensaje contiene:
• Una variedad de salidas: una o más direcciones que reciben los bytes y las cantidades que reciben.
• Una serie de entradas: una o más referencias a productos anteriores que se utilizan para financiar el
transferir. Estos son productos que fueron enviados a las direcciones de autor en el pasado y no son
aún gastado.
La suma de las entradas debe ser igual a la suma de las salidas más las comisiones (se leen las cantidades de
entrada)
de productos anteriores y no están explícitamente indicados cuando se gasta). La unidad está firmada con el
claves privadas del autor
El número total de bytes en circulación es 1015, y este número es constante.
Todos los bytes se emiten en la unidad de génesis, luego se transfieren de usuario a usuario. Los honorarios
son recolectados por
otros usuarios que ayudan a mantener la red saludable (más detalles al respecto más adelante), para que
permanezcan en circulación.
El número 1015 se seleccionó como el número entero redondo más grande que se puede representar en
JavaScript.
Las cantidades solo pueden ser enteros. Las unidades más grandes de la moneda se obtienen aplicando
estándar
prefijos: 1 kilobyte (Kb) es 1,000 bytes, 1 megabyte (Mb) es 1 millón de bytes, etc.
6.3 DOBLE-GASTOS
Si un usuario intenta gastar el mismo resultado dos veces, hay dos situaciones posibles:
1. Existe un orden parcial entre las dos unidades que intentan gastar la misma salida, es decir, una de
las unidades (directa o indirectamente) incluyen la otra unidad y, por lo tanto, viene después. En esto
caso, es obvio que podemos rechazar con seguridad la unidad posterior.
2. No hay un orden parcial entre ellos. En este caso, aceptamos ambos. Establecemos un orden total
entre las unidades más adelante, cuando están enterradas lo suficientemente profundo bajo unidades más
nuevas (ver
a continuación, cómo lo hacemos). El que aparece antes en el orden total se considera válido, mientras que
el otro se considera inválido.
18
Existe una regla de protocolo más que simplifica la definición de orden total. Requerimos, que si el
la misma dirección publica más de una unidad, debe incluir (directa o indirectamente) todas sus unidades
anteriores
en cada unidad subsiguiente, es decir, debería haber un orden parcial entre unidades consecutivas de la
misma
dirección. En otras palabras, todas las unidades del mismo autor deben ser seriales.
Si alguien rompe esta regla y publica dos unidades de manera que no haya un orden parcial entre ellas
(unidades no militares), las dos unidades se tratan como gastos dobles incluso si no intentan gastar el
mismo resultado. Tales no sériales se manejan como se describe en la situación 2 anterior.
Si un usuario sigue esta regla pero aún intenta gastar el mismo resultado dos veces, se gastan los doble-
gastos
ordenado inequívocamente y podemos rechazar con seguridad el último como en la situación 1 anterior. Los
dobleces
que no son no séricos al mismo tiempo se filtran fácilmente.
Esta regla es de hecho bastante natural. Cuando un usuario compone una nueva unidad, selecciona la más
reciente
unidades como padres de su unidad. Al ponerlos en la lista de sus padres, él declara su imagen del mundo,
lo que implica que ha visto estas unidades.
Por lo tanto, ha visto a todos los padres de padres, padres de padres, etc. hasta la génesis
unidad. Este gran conjunto obviamente debe incluir todo lo que él mismo ha producido, y por lo tanto
ha visto.
Al no incluir una unidad (incluso indirectamente, a través de los padres), el usuario niega haberla visto. Si
vemos
que al no incluir su unidad anterior un usuario niega haberla visto, diríamos que es extraña, algo
Fishy está pasando. Desanimamos tal comportamiento.
6.4 LA CADENA PRINCIPAL
Nuestro DAG es un DAG especial. En el uso normal, la gente vincula principalmente sus nuevas unidades a
algo menos recientes
unidades, lo que significa que el DAG crece solo en una dirección. Uno puede imaginarlo como un cable
grueso con muchas
alambres entrelazados adentro. Esta propiedad sugiere que podríamos elegir una sola cadena a lo largo del
niño-padre
enlaces dentro del DAG, y luego relacione todas las unidades con esta cadena. Todas las unidades se
encontrarán directamente en
esta cadena, a la que llamaremos cadena principal, o puede accederse a ella por un número relativamente
pequeño de
salta a lo largo de los bordes del gráfico. Es como una carretera con conexiones de caminos laterales.
Una forma de construir una cadena principal es desarrollar un algoritmo que, dados todos los padres de una
unidad, seleccione uno
de ellos como el "mejor padre". El algoritmo de selección debe basarse únicamente en el conocimiento
disponible
19
a la unidad en cuestión, es decir, sobre los datos contenidos en la unidad misma y todos sus antepasados. A
partir de cualquier
consejo (una unidad sin hijos) del DAG, luego retrocedemos en la historia a lo largo de los mejores enlaces
para padres.
Viajando de esta manera, construimos una cadena principal y eventualmente llegamos a la unidad de
génesis.
Tenga en cuenta que la cadena principal construida a partir de una unidad específica nunca cambiará a
medida que se agreguen nuevas unidades.
Esto se debe a que en cada paso estamos viajando de niño a padre, y una unidad existente nunca puede
adquirir
nuevos padres.
Si comenzamos desde otro consejo, construiremos otra cadena principal. De nota aquí es que si esos dos
principales
cadenas alguna vez se cruzan mientras que retroceden en la historia, ambos seguirán el mismo camino
después de la
punto de intersección. En el peor de los casos, las cadenas principales se cruzan solo en génesis. Dado que el
proceso de producción unitaria no se coordina entre los usuarios, sin embargo, uno podría esperar encontrar
un
clase de cadenas principales que convergen no muy lejos de las puntas.
Una vez que tenemos una cadena principal (MC), podemos establecer un orden total entre dos productos no
séricos conflictivos
unidades. Primero indexemos las unidades que se encuentran directamente en la cadena principal. La unidad
de génesis tiene índice 0, el
la siguiente unidad de MC que es hija de génesis tiene el índice 1, y así, al avanzar a lo largo de la MC, le
asignamos
índices a unidades que se encuentran en el MC. Para las unidades que no se encuentran en el MC, podemos
encontrar un índice MC
donde esta unidad se incluye por primera vez (directa o indirectamente). De esta forma, podemos asignar un
índice MC
(MCI) a cada unidad.
Entonces, de los dos no seropositivos, se considera que el que tiene un MCI más bajo viene antes y se
considera
válido, mientras que el otro es inválido. Si ambos no sériales tienen el mismo MCI, hay un desempate
dicta que la unidad con el valor hash más bajo (como se representa en la codificación base64) es válida.
Tenga en cuenta que
guardamos todas las versiones del doble gasto, incluidas las que eventualmente pierden. DagCoin [3] fue el
primer trabajo publicado que sugirió almacenar todas las transacciones en conflicto y decidir cuál de ellas
tratar como válido
El MC construido a partir de una unidad específica nos dice qué piensa el autor de esta unidad sobre el orden
del pasado
eventos, es decir, su punto de vista sobre la historia. La orden entonces implica qué unidad no-militar
considerar
válido, como se describe arriba. Tenga en cuenta que al elegir el mejor padre entre todos los padres de un
determinado
unidad, estamos haciendo simultáneamente una elección entre sus MC: el MC de la unidad en cuestión será
el MC de su mejor padre extendido hacia adelante por un enlace.
Reconociendo que muchas (o incluso todas) las unidades de los padres podrían ser creadas por un atacante y
recordando
que la elección del mejor padre es esencialmente la elección entre las versiones de la historia, debemos exigir
20
de nuestro mejor algoritmo de selección de padres que favorece las historias que son "reales" desde el punto
de vista
de la unidad infantil. Por lo tanto, necesitamos diseñar una "prueba de realidad" que nuestro algoritmo
ejecute contra todos
MC candidatos para seleccionar el que mejor puntúa.
6.5 TESTIGOS
Buscando una "prueba de realidad", observe que algunos de los participantes de nuestra red no son
anónimos
personas o empresas de buena reputación que puedan tener una reputación establecida desde hace mucho
tiempo, o que sean empresas
interesado en mantener la red saludable. Los llamaremos testigos. Si bien es razonable esperar
Para comportarse honestamente, tampoco es razonable confiar totalmente en un solo testigo. Si conocemos
el
Direcciones de Byteball de varios testigos, y también esperan que publiquen con suficiente frecuencia, luego
a
medir la realidad de un MC candidato, uno podría viajar a lo largo del MC en el tiempo y contar el testimonio
del autor
unidades (si el mismo testigo se encuentra más de una vez, no se lo vuelve a contar).
Dejaríamos de viajar tan pronto como nos encontráramos con la mayoría de los testigos. Nosotros entonces
mida la longitud de la ruta más larga en el gráfico desde el punto en que nos detuvimos hasta la génesis.
Llamaremos a esta longitud el nivel de la unidad donde nos detuvimos, y el nivel observado de los padres
de quién MC estamos probando. El candidato MC que rinde el mayor nivel observado es considerado
más "real", y el padre que lleva este MC se selecciona como mejor padre. En caso de que haya varios
contendientes
con un nivel máximo atestiguado, seleccionamos el padre cuyo nivel es el más bajo. Si el empate
persiste, seleccionamos el padre con el hash de unidad más pequeño (en codificación base64).
Este algoritmo permite la selección del MC que gravita a unidades creadas por testigos, y el
los testigos se consideran representativos de la realidad. Si, por ejemplo, un atacante se bifurca del
parte honesta de la red y secretamente construye una larga cadena de sus propias unidades (cadena de
sombra), una de
ellos contienen un doble gasto, y luego fusiona su tenedor de nuevo en el DAG honesto, el mejor padre
algoritmo de selección en el punto de fusión elegirá el padre que conduce el MC en el honesto
DAG, ya que aquí es donde los testigos estaban activos. Los testigos no pudieron publicar en la sombra
cadena simplemente porque no lo vieron antes de la fusión. Esta selección de MC refleja el orden de
eventos según lo visto por los testigos y el usuario que los designó. Después de que termine el ataque, la
totalidad
la cadena de sombras aterrizará en el MC en un punto, y el doble gasto
contenido en la cadena paralela se considerará inválido porque su contraparte válida es anterior,
antes del punto de fusión.
Este ejemplo muestra por qué se debe confiar en que la mayoría de los testigos publiquen solo en serie. La
mayoría
no debe coludirse con el atacante y publicar en su cadena de sombras. Tenga en cuenta que confiamos en los
testigos
solo para ser signos de realidad y para no publicar unidades no militares en ninguna cadena de sombras. No
somos
dando a cualquiera de ellos control sobre la red o cualquier parte de ella. Incluso para este pequeño deber,
son los usuarios
quienes nombran a los testigos y pueden cambiar sus decisiones en cualquier momento.
La idea de mirar a una entidad conocida como un signo de realidad no es nueva. Se sabe desde hace tiempo,
y
algunas empresas han participado en dicha actividad, que para demostrar que algunos datos existían antes
de un específico
fecha, uno puede codificar los datos y publicar el hash en algunos medios difíciles de modificar y
ampliamente atestiguados,
como el periódico impreso. Los testigos en Byteball cumplen la misma función que el periódico.
Al igual que los periódicos, son bien conocidos y de confianza. En cuanto a los periódicos donde la confianza
se limita a confiar
para publicar los datos que se les entregan, solo se confía en que los testigos en Byteball publiquen en serie,
y no mucho más Al igual que los periódicos, los testigos no saben qué hay detrás de los hashes que están
presenciando
y tiene pocas razones para cuidar mejor a los padres.
Los periódicos son difíciles de modificar (pero es posible, y en 1984 lo hacen), mientras que todo lo que
produce es
los testigos están protegidos por firmas digitales, lo que imposibilita cualquier modificación. Para
confiabilidad,
tenemos varios testigos, no solo uno, y para mayor rapidez y conveniencia, estos están en línea.
Después de haber decidido una lista de testigos, podemos seleccionar mejor el padre y el historial
correspondiente
que mejor se ajusta a la definición de realidad como "en algún lugar donde viven estos testigos". Al mismo
tiempo, los propios padres podrían tener diferentes listas de testigos y, en consecuencia, diferentes
definiciones
de la realidad Queremos que converjan las definiciones de realidad y las historias que se derivan de ellas
alrededor de algo común. Para lograr esto, presentamos la siguiente regla de protocolo adicional.
La "regla de la casi conformidad": los mejores padres deben seleccionarse solo entre los padres cuyo testigo
la lista difiere de la lista de testigos del niño por no más de una mutación. Esta regla asegura que el testigo
las listas de unidades vecinas en el MC son lo suficientemente similares, por lo tanto, sus historias coinciden
principalmente con
unos y otros. Los padres cuya lista de testigos difiere en 0 o 1 mutación se llamará compatible (con
la unidad que los incluye directamente), mientras que los otros son incompatibles. Los padres incompatibles
todavía están
permitido, pero no tienen ninguna posibilidad de convertirse en el mejor padre. Si no hay un potencial
compatible
padres entre unidades sin hijos (un atacante podría inundar la red con sus unidades que llevan un
lista de testigos diferentes), uno debe seleccionar padres de unidades más antiguas.
Lo anterior significa que cada unidad debe listar a sus testigos para que puedan ser comparados.
Necesitamos
que el número de testigos es exactamente 12. Este número 12 fue seleccionado porque:
• es lo suficientemente grande para proteger contra las fallas ocasionales de unos pocos testigos (podrían
demuestre ser deshonesto, o ser pirateado, o desconectarse por un tiempo prolongado, o perder sus llaves
privadas e irse
fuera de línea para siempre);
• es lo suficientemente pequeño como para que los humanos puedan hacer un seguimiento de todos los
testigos para saber quién es quién
y cambie la lista cuando sea necesario;
• la única mutación permitida es suficientemente pequeña en comparación con los 11 testigos sin cambios.
En caso de que un usuario piense que alguno de los testigos ha perdido su credibilidad, o simplemente hay
mejores candidatos,
el usuario puede reemplazar al testigo con un nuevo testigo en su lista, teniendo en cuenta que su testigo
la lista no puede diferir de la de otras unidades en más de una posición. Esto significa que cualquier cambio
puede suceder solo de forma gradual, y se requiere un consenso general para un cambio mayor que una
posición.
6.6 FINALIDAD
A medida que llegan nuevas unidades, cada usuario realiza un seguimiento de su MC actual que está
construido como si fuera a emitir
una nueva unidad basada en todas las unidades sin hijos actuales. El MC actual puede ser diferente en
diferentes nodos
porque pueden ver diferentes conjuntos de unidades sin hijos. Requerimos que el MC actual se construya sin
Respecto de las listas de testigos, es decir, la lista de testigos del usuario no es relevante e incluso los padres
incompatibles
pueden ser seleccionados como mejores padres. Eso significa que si dos usuarios tienen el mismo conjunto
de sin hijos
unidades, pero tienen listas de testigos diferentes, sus MC actuales seguirán siendo idénticos. El actual MC
cambian constantemente a medida que llegan nuevas unidades. Sin embargo, como estamos a punto de
mostrar, una parte de la MC actual
eso es lo suficientemente viejo como para permanecer invariante.
Esperamos que los testigos (o más bien la mayoría de ellos) se comporten con honestidad, por lo tanto,
necesariamente incluyen
su unidad anterior en la siguiente unidad creada por el mismo testigo. Esto significa que cuando un testigo
compone una nueva unidad, solo las unidades recientes son candidatas para ser elegidas como padres.
Podríamos esperar,
por lo tanto, que todos los MC actuales no convergerán más (al retroceder en el tiempo)
que un punto de estabilidad particular. De hecho, la unidad de génesis es un punto de estabilidad inicial
natural.
Supongamos que hemos construido un MC actual basado en el conjunto actual de unidades sin hijos, y hubo
algunos
señalar en este MC que se creía que era estable, es decir, que se cree que todos los futuros MC actuales
converger en o antes de este punto (nuevamente, cuando retrocede en el tiempo), y luego viajar a lo largo
del mismo
ruta. Si podemos encontrar una manera de avanzar este punto hacia adelante (lejos de la génesis), podemos
probar por
inducción de que existe un punto de estabilidad.
Tenga en cuenta que si nos olvidamos de todos los padres, excepto el mejor padre, nuestro DAG se reducirá a
un árbol
que consiste solo en los mejores enlaces principales. Obviamente, todos los MC irán a lo largo de las ramas
de este árbol. Nosotros
luego hay que considerar dos casos: cuando el árbol se ramifica en el punto de estabilidad actual y cuando
no lo hace, y decide si podemos avanzar el punto de estabilidad al siguiente MCI.
Primero, suponga que el árbol no se ramifica. Entonces debemos considerar la posibilidad de que una nueva
sucursal
aún se agregarán y de alguna manera serán respaldados por los testigos para que supere la rama existente.
La otra posibilidad es que los testigos hayan puesto tanto peso en apoyo de la sucursal existente, que
el
requisito de incluir la unidad previa de uno no les deja opciones, sino continuar apoyando el existente
rama. Cuantifiquemos la última posibilidad.
Recuerde que el mejor padre se selecciona como el padre con el mayor nivel atestiguado. Vamos a viajar
retroceda en el tiempo a lo largo del MC actual desde la punta hasta que nos encontremos con la mayoría de
los testigos (nos referimos
a los testigos definidos por la unidad que se encuentra en el punto de estabilidad actual). Si al menos uno de
ellos
miente antes que el punto de estabilidad actual, no tratamos de avanzar el punto de estabilidad, de lo
contrario,
proceder. En este caso, todos estos testigos ya están "invertidos" en el MC actual. Entre estos
testigos, encontramos el mínimo testigo nivel min_wl. Cuando cualquiera de estos testigos publica un nuevo
unidad, esta unidad podría tener padres cuya MC conduce a la MC actual y padres cuya MC conduce a
una rama competidora, y el padre con el nivel más alto testigo será seleccionado como el mejor padre
y definirá la dirección del próximo MC actual. Dado que el testigo debe incluir su anterior
unidad, el nivel de testigo del padre que conduce a la MC actual será al menos min_wl.
El nivel observado de cualquier padre que conduzca a la sucursal alternativa nunca excederá el nivel del
punto de estabilidad actual, incluso si todos los testigos restantes (minoritarios) se congregan en la sucursal
alternativa.
Por lo tanto, si el MC actual crece lo suficiente para que min_wl sea mayor que el nivel de la corriente
punto de estabilidad, la mayoría de los testigos tendrán que aumentar el apoyo para el MC actual existente,
el
una sucursal alternativa ha perdido todas las oportunidades de ganar, y podemos mover el punto de
estabilidad hacia adelante para
el próximo MCI.
Luego, suponga que el árbol tiene ramificación. Necesitamos encontrar una condición donde las ramas
alternativas
perder cualquier posibilidad de superar el actual MC. Comencemos definiendo min_wl como en el caso
anterior.
Entre todas las unidades en las ramas alternativas, seleccionamos aquellas que aumentan el nivel de testigo,
es decir
su propio nivel atestiguado es mayor que el de cada padre. Entre estos, encontramos el máximo
nivel. Entonces, incluso si todos los testigos restantes (minoritarios) se reúnen en las sucursales alternativas,
el testigo
nivel en las ramas alternativas nunca excederá este nivel máximo. Por lo tanto, si esto
el nivel máximo es menor que min_wl, el juego ha terminado para las ramas alternativas, y podemos avanzar
el punto de estabilidad a lo largo del MC actual.
Por lo tanto, hay un punto en el MC actual antes del cual el MC nunca cambiará (suponiendo que la mayoría
de testigos no publican unidades no militares). El orden total definido relativo a este MC es por lo tanto
también final. Si tuviéramos no sériales, nuestra decisión sobre cuál de ellos es válida también es definitiva. Si
es nuevo
nunca aparece algo no verbal que entra en conflicto con algo que ya está en el MC estable, la nueva unidad
no-militar
se ordenará definitivamente después de la contraparte anterior, y la nueva será considerada inválida. Por lo
tanto,
cualquier pago realizado en la unidad incluida en el MC estable ya es irreversible. A diferencia de Bitcoin
donde la finalidad de la transacción es solo probabilística, esta es la finalidad determinista de la transacción.
Cada usuario construye su propia MC (subjetiva) actual basada en las unidades que ve. Desde la propagación
de nuevas unidades no es instantáneo, y pueden llegar en diferente orden a diferentes usuarios, los usuarios
tendrá diferentes MC actuales y diferentes opiniones sobre el último punto estable de la MC en cualquier
tiempo dado.
Sin embargo, dado que el MC actual se define únicamente por el conjunto de unidades conocidas por el
usuario, en caso de que el usuario B
aún no ha avanzado su punto de estabilidad al mismo MCI que el usuario A, inevitablemente lo hará más
tarde, es decir,
tan pronto como reciba las mismas unidades que el usuario A, o más. Por lo tanto, las opiniones de diferentes
usuarios sobre
el estado de cualquier unidad dada es eventualmente constante.
6.7 ALMACENAMIENTO DE UNIDADES NO CONSULTIVAS
Cuando decidimos que una unidad es no-militar, todavía tenemos que almacenarla. Sin embargo, parte de su
información es reemplazada
con un hash de los datos. Esta regla tiene dos propósitos. Primero, para reducir el almacenamiento
consumido por un
unidad que nadie pagó (el contenido completo de la unidad no interna se considera inválido, incluido su
pago de comisiones). En segundo lugar, para reducir la utilidad de lo no sérico para el usuario que lo envió,
porque
el hash
reemplaza todos los datos útiles que el autor quería almacenar (gratis). Esto evita que los atacantes abusen
no sériales como una forma de almacenar grandes cantidades de datos de forma gratuita.
El hash que se almacena en lugar del contenido completo todavía tiene cierta utilidad para el atacante, ya
que puede almacenar
los datos originales y usar el hash para demostrar que los datos existieron. Pero recuerda eso:
1. Todavía tiene que pagar por una unidad que se considera válida
2. Si el atacante ya está almacenando internamente metadatos que son necesarios para interpretar Byteball
datos, él podría hacerlo igualmente bien simplemente combinando todos sus datos en un árbol de Merkle y
usando
Byteball para almacenar solo su raíz de Merkle por el costo de una unidad pequeña.
Bajo este diseño, por lo tanto, no hay interés propio en tratar de enviar no sériales.
Debería mencionarse que no podemos simplemente rechazar los no sériales la primera vez que los vemos. Si
lo hiciéramos,
un atacante podría enviar sus no sériales a diferentes usuarios en diferente orden. Diferentes usuarios
entonces
apegarse a las versiones que recibieron por primera vez y rechazar todo en función de la otra versión, por lo
que el atacante
tendría éxito en la partición de la red. Es por eso que tenemos que almacenar ambas versiones y
luego decide sobre su orden. Aún más, los usuarios deben enviar no sériales a sus compañeros como
cualquier otro
unidades, ya que cuanto más pronto aprendan los compañeros sobre los no sériales, mejor.
Aún así, intentamos evitar incluir no sériales si es posible: el algoritmo de selección de padres excluye a los no
siales
mientras no tengan hijos. Por esta razón, es deseable ayudar a los compañeros a aprender sobre los no
sériales como
tan pronto como sea posible.
6.8 BOLAS
Después de que una unidad se vuelve estable (es decir, se incluye en la parte estable de la MC) creamos una
nueva estructura
basado en esta unidad, lo llamamos bola:
Cada pelota incluye información sobre todas sus bolas ancestrales (a través de los padres), de ahí la cantidad
de información
Depende de que crezca como bola de nieve. También tenemos una bandera en el balón que nos dice si
terminó
siendo inválido (no sérico), y tenemos referencias a bolas más antiguas que usaremos más tarde para
construir pruebas para
clientes ligeros.
Solo podemos construir una pelota cuando la unidad correspondiente se estabilice y sabemos con certeza
si es serial. Dado que los MC actuales según los usuarios diferentes son finalmente consistentes,
todos construirán exactamente la misma pelota basada en la misma unidad.
6.9 ÚLTIMA PELOTA
Para proteger las bolas (lo más importante, el indicador is_nonserial) de la modificación, requerimos cada
nuevo
unidad para incluir un hash de la última bola que el autor conoce (que es la bola construida a partir del último
unidad estable, y se encuentra en el MC). De esta manera, la última bola estará protegida por la firma del
autor.
Más adelante, la nueva unidad en sí misma será (directa o indirectamente) incluida por los testigos.
Si alguien que no tiene toda la base de datos de Byteball quiere saber si una unidad en particular es serial,
nos daría una lista de testigos en los que confía para comportarse honestamente, y construiríamos una
cadena de recientes
unidades que incluyen la mayoría de dichos testigos, luego lea la última bola de la unidad más antigua de
la cadena, y usa bolas para construir un árbol hash que tiene la última bola en la parte superior e incluye lo
solicitado
unidad en algún lugar abajo. Este árbol hash es similar a un árbol Merkle muy alto, con
datos alimentados en cada nodo. El árbol se puede optimizar utilizando la lista de skiplists.
La referencia a la última bola también permite a los usuarios ver lo que piensan sus compañeros sobre el
punto de estabilidad de la
MC y compararlo con su propia visión.
También requerimos que la última bola quede antes de la última bola de cada padre. Esto asegura que el
La última bola avanza hacia delante a lo largo del MC o se mantiene en la misma posición, pero nunca
retrocede.
Para reducir aún más los grados de libertad de los adversarios, agregamos un requisito más: el testimonio de
una unidad
la lista debe ser compatible con la de cada unidad que se encuentra en la parte posterior del MC de la unidad
entre
esta unidad y la unidad de la última bola.
Este requisito garantiza que todos los cambios en la lista de testigos lleguen primero al punto de estabilidad
antes de intentar
otro cambio. De lo contrario, un atacante podría inyectar una lista de testigos significativamente modificada
en el MC
y dejar de publicar desde las direcciones de los nuevos testigos. En tales casos, el punto de estabilidad
no sería capaz de avanzar más allá del tramo ocupado por los testigos del atacante.
El requisito de que las listas de testigos de todas las unidades contemporáneas sean en su mayoría similares
significa que todos los usuarios
tener opiniones en su mayoría similares sobre a quién se puede confiar para servir como faros para la
comunidad en el
26
tiempo actual. Esto es similar a la biología, donde los organismos de la misma especie tienen que tener
principalmente la
mismos genes.
La pequeña variación de la lista de testigos permite un cambio evolutivo que aún conserva la integridad de
el sistema.
6.10 UNIDAD DE LISTA DE TESTIGOS
Se espera que muchos usuarios deseen utilizar exactamente la misma lista de testigos. En este caso, para
guardar
espacio, no enumeran las direcciones de los 12 testigos. Por el contrario, dan una referencia a otro anterior
unidad, que enumeró a estos testigos explícitamente.
La unidad de lista de testigos debe ser estable desde el punto de vista de la unidad de referencia, es decir,
debe estar incluida
en la última unidad de bola.
6.11 ESTRUCTURA DE LA UNIDAD
Este es un ejemplo de una unidad:
Aquí:
• versión es el número de versión del protocolo. La unidad se interpretará de acuerdo con esta versión
del protocolo;
• alt es un identificador de moneda alternativa, lo discutiremos más adelante;
• mensajes es una matriz de uno o más mensajes que contienen datos reales;
o aplicación es el tipo de mensaje, p. 'Pago' por pagos, 'texto' por mensajes de texto arbitrarios,
etc .;
o payload_location dice dónde encontrar la carga útil del mensaje. Puede ser 'en línea' si la carga útil
está incluido en el mensaje, 'uri' si la carga útil está disponible en una dirección de Internet,
28
'Ninguno' si la carga útil no se publica en absoluto, se almacena y / o se comparte de forma privada, y
payload_hash sirve para probar que existió en un momento específico;
o payload_hash es un hash de la carga útil en la codificación base64;
o la carga útil es la carga real (ya que está "en línea" en este ejemplo). La estructura de carga
es específico de la aplicación. Los pagos se describen de la siguiente manera:
▪ inputs es una matriz de monedas de entrada consumidas por el pago. Todos los propietarios de la
las monedas de entrada deben estar entre los firmantes (autores) de la unidad;
• unidad es hash de la unidad donde se produjo la moneda.
Para ser gastable, la unidad debe incluirse en last_ball_unit;
• message_index es un índice en la matriz de mensajes de la unidad de entrada.
Indica el mensaje donde se produjo la moneda;
• output_index es un índice en el array outputs del message_index'th
mensaje de la unidad de entrada. Indica el resultado donde el
la moneda fue producida;
▪ outputs es una matriz de resultados que dicen quién recibe el dinero;
• dirección es la dirección de Byteball del destinatario;
• cantidad es la cantidad que recibe;
• authors es una matriz de los autores que crearon y firmaron esta unidad. Todas las monedas de entrada
deben pertenecer
a los autores;
o la dirección es la dirección Byteball del autor;
o autentificadores es una estructura de datos que prueba la autenticidad del autor. Más comúnmente
estas son firmas ECDSA;
• parent_units es una matriz de valores hash de unidades principales. Debe ser ordenado alfabéticamente;
• last_ball y last_ball_unit son hashes de last ball y su unidad, respectivamente;
• test_list_unit es hash de la unidad donde se puede encontrar la lista de testigos.
Todos los hashes están en codificación base64.
Tenga en cuenta que no hay un campo de marca de tiempo en la estructura de la unidad. En Byteball, no hay
reglas de protocolo
que dependen del tiempo del reloj. simplemente no es necesario, ya que es suficiente confiar en el orden de
los eventos solo.
La marca de tiempo todavía se agrega a las unidades cuando se envían de un nodo a otro. Sin embargo, esto
es solo
asesor y utilizado por clientes ligeros para mostrar en carteras el tiempo aproximado cuando se produjo una
unidad,
que puede diferir significativamente del momento en que se recibió, ya que los clientes ligeros pueden
desconectarse
períodos prolongados de tiempo
6.12 COMISIONES
Como se mencionó anteriormente, el costo de almacenar una unidad es su tamaño en bytes. La comisión se
divide en dos
partes: comisión de encabezados y comisión de carga. La comisión de carga útil es igual al tamaño de los
mensajes;
la comisión de encabezados es del tamaño de todo lo demás. Los dos tipos de comisiones se distribuyen
diferentemente.
La comisión de encabezados va a una de las unidades futuras que toma la unidad de orden como padre. El
receptor
se selecciona solo después de que tanto el MCI de la unidad del pagador como el siguiente MCI se
estabilicen. Para determinar
el receptor, tomamos aquellos niños cuya MCI es igual o 1 más que el MCI del pagador. los
hashes de cada uno de estos niños se concatenan con el hash de la unidad que se encuentra en el siguiente
MCI
(relativo al pagador), y el niño con el valor de hash más pequeño (en hex) gana la comisión de encabezados.
Este hash con la próxima unidad MC está diseñado para introducir impredecibilidad (la siguiente unidad MC
es
29
no conocido de antemano) y hace inútil cualquier intento de mejorar las posibilidades de recibir una comisión
jugando con el hash de la propia unidad. Al mismo tiempo, restringir candidatos a aquellos cuya
MCI no es más de 1 mayor que el MCI del pagador, incentiva la selección del más reciente
unidades como padres. Esto es útil para mantener el DAG lo más estrecho posible.
Pagamos solo la comisión de encabezados y no toda la comisión a aquellos que son rápidos para elegir
nuestra unidad como padre, por el siguiente motivo. Si pagamos toda la comisión, habríamos incentivado
comportamiento abusivo: dividir los datos en varios fragmentos y construir una larga cadena de los propios
unidades que almacenan un pedazo por unidad. Todas las comisiones pagadas en una unidad anterior serían
entonces inmediatamente
recogidos por el mismo usuario en la siguiente unidad. Como solo pagamos la comisión de encabezados,
dicho comportamiento
no es rentable porque para producir cada elemento adicional de la cadena uno tiene que gastar
comisión de encabezados adicionales: aproximadamente el mismo que uno gana. Usamos el remanente
(carga útil)
comisión para incentivar a otros cuya actividad es importante para mantener la red saludable.
La comisión de la carga útil va a los testigos. Para incentivar a los testigos a publicar con la frecuencia
suficiente, nos dividimos
la comisión de carga útil por igual entre todos los testigos que son lo suficientemente rápidos para publicar
dentro de los 100 índices de MC
después de la unidad de pago (cuanto más rápido publiquen, más rápido se estabilizará esta unidad). Si los 12
testigos
publicado dentro de este intervalo, cada uno recibe 1/12 de la comisión de carga útil. Si solo uno
testigo ha publicado, recibe toda la comisión de carga útil. En el caso especial que no testigo
ha publicado dentro de este intervalo, todos reciben 1/12 de comisión de carga útil. Si la división produce un
número fraccionario, se redondea según las reglas matemáticas. Debido a este redondeo, el total
la comisión pagada a los testigos puede no ser igual a la comisión de carga total recibida de
el
autor (es) de la unidad, por lo que la oferta monetaria total también cambiará ligeramente. Obviamente, la
distribución
ocurre solo después de que MCI + 100 se estabiliza, donde MCI es el MCI de la unidad que paga.
Para gastar las comisiones de encabezados ganados o testigos de comisiones, se utiliza la siguiente entrada:
Tales entradas barren todos los encabezados o testigos de las comisiones ganadas por el autor de la comisión
pagando unidades que se emitieron entre los principales índices de cadena de_main_chain_index y
to_main_chain_index. Naturalmente, to_main_chain_index debe ser estable.
30
Cuando una unidad firmada por más de un autor gana la comisión de encabezados, existe una ambigüedad
tan grande como
a cómo la comisión se divide entre los autores. Para eliminar la ambigüedad, cada unidad que está firmada
por más de un autor debe incluir una estructura de datos que describa las proporciones de los ingresos
compartiendo:
Las direcciones que reciben las comisiones no tienen que ser las mismas ya que el autor se dirige a la
comisión
se puede enviar a cualquier dirección. Incluso si la unidad está firmada por un solo autor, puede incluir esto
campo para redirigir las comisiones de encabezados a otra parte.
6.13 TIEMPO DE CONFIRMACIÓN
El tiempo de confirmación es el tiempo desde que una unidad ingresa a la base de datos hasta alcanzar la
estabilidad. Depende de
con qué frecuencia publican los testigos, ya que para alcanzar la estabilidad necesitamos acumular suficientes
testimonios
unidades en el MC después de la unidad recién agregada. Para minimizar el período de confirmación, los
testigos
debe publicar con la frecuencia suficiente (que ya están incentivados a hacer a través de la distribución de
comisiones)
reglas) pero no con demasiada frecuencia. Si dos o más testigos emiten sus unidades casi simultáneamente
(más rápido de lo que normalmente se necesita para propagar una nueva unidad a otros testigos), esto
puede causar innecesarios
bifurcación del árbol compuesto por enlaces del mejor padre, lo que retrasaría la estabilidad. Para esto
razón, los mejores tiempos de confirmación se alcanzan cuando los testigos están bien conectados y se
ejecutan en
máquinas rápidas para que puedan validar rápidamente nuevas unidades. Estimamos la mejor confirmación
tiempos de alrededor de 30 segundos; esto solo es alcanzable si el flujo de unidades nuevas es lo
suficientemente grande para que
los testigos ganan más al ser testigos de las comisiones que gastan en publicar sus propias unidades.
A pesar de que el período de confirmación completa es bastante largo, un nodo que confía en sus pares para
entregar todos
las nuevas unidades sin filtro pueden estar razonablemente seguras de que una vez que una unidad fue
incluida por al menos un testigo,
más una latencia típica que ha transcurrido (el tiempo que le toma a una nueva unidad viajar de igual a igual),
el
la unidad probablemente alcanzará la finalidad y se considerará válida. Incluso si un doble gasto aparece más
tarde, lo hará
probablemente sea ordenado después de esta unidad.
6.14 RIESGO DE PARTICION
La red de nodos Byteball nunca se puede dividir en dos partes que continuarían funcionando
sin darse cuenta. Incluso en el caso de una interrupción de la red global, como una rata subatlántica
cortando el cable que conecta Europa y América, al menos uno de los lados de la división se dará cuenta
que ha perdido la mayoría de los testigos, lo que significa que no puede avanzar el punto de estabilidad, y
nadie
poder
gastar salidas atrapadas en la parte inestable de la MC. Incluso si alguien intenta enviar un gasto doble,
seguirá siendo inestable (y, por lo tanto, no reconocido) hasta que se restablezca la conexión. La otra parte
de
la división donde la mayoría de los testigos pasan a ser, continuará como siempre
6.15 CENSURA
Por diseño, ya es imposible modificar o borrar los registros pasados en Byteball. También es bastante difícil
para evitar que tipos particulares de datos ingresen a la base de datos.
En primer lugar, los datos en sí mismos pueden ocultarse y solo se debe publicar su hash en la base de datos
para demostrar
que los datos existieron. Los datos solo pueden revelarse después de almacenar el hash y su unidad ha sido
incluido por otras unidades para que se haya vuelto irrevisible.
En segundo lugar, incluso cuando los datos están abiertos, se delega la decisión de incluirlos o no en la base
de datos.
a numerosos usuarios anónimos que podrían (y de hecho se les incentiva) tomar la nueva unidad como
un padre. Alguien que intente censurar unidades indeseables no solo deberá evitar incluirlas
directamente (como padres) pero también indirectamente, a través de otras unidades. (Esto es diferente de
Bitcoin, donde
los mineros o grupos de minería pueden, y lo hacen, filtrar transacciones individuales directamente. Además,
los usuarios de Bitcoin tienen
no se puede decir quién se convertirá en minero.) Como el número de unidades que incluyen la unidad
"ofensiva"
bolas de nieve, cualquier intento de evitarlo implicaría censurarse a sí mismo. Solo la mayoría de los testigos
pueden
imponer efectivamente reglas de contenido prohibido, si los usuarios eligen a esos testigos.
6.16 ESCOGER TESTIGOS
La confianza en los testigos es lo que hace que Byteball se arraigue en el mundo real. Al mismo tiempo, lo
hace
altamente dependiente de las decisiones humanas. La salud del sistema depende de que los usuarios
establezcan de manera responsable
las listas de testigos en las que sí confían Este proceso no se puede automatizar de manera segura, por
ejemplo, si la mayoría de los usuarios
comience a actualizar sus listas de testigos para que coincidan con las listas de las unidades observadas más
recientemente, solo para ser
compatible, esto puede ser fácilmente explotado por un atacante que inunda la red con sus propias unidades
que cambia gradualmente la lista de testigos predominante a algo que el atacante elija.
Mientras que la recomendación maximalista podría ser "solo edite las listas de testigos manualmente", lo
cual es demasiado oneroso
para la mayoría de los usuarios, un enfoque más práctico para la gestión de la lista de testigos es el
seguimiento y de alguna manera
promediando las listas de testigos de unos pocos "capitanes de la industria" que tienen interés en cuidar
la salud de la red o que se han ganado una buena reputación en actividades no necesariamente conectadas
con Byteball. Algunos de ellos pueden ser testigos presenciales.
A diferencia de las listas de testigos, las listas de capitanes de la industria no tienen que ser compatibles y no
actualizarse
la lista con la frecuencia suficiente no tiene implicaciones negativas inmediatas, como no poder
encontrar padres compatibles y publicar una nueva unidad. Esperamos que la mayoría de los usuarios usen
uno de
pequeño número de carteras más populares, y tales carteras se configurarán de forma predeterminada para
seguir el
lista de testigos del vendedor de monedero, que a su vez probablemente mira las listas de testigos de otros
jugadores prominentes.
Los testigos también tienen sus listas de testigos, y se recomienda que los usuarios elijan a esos testigos
en quién confían para mantener sus listas de testigos representativas de las creencias de los usuarios
comunes. Esto es muy importante
porque ningún cambio en la lista de testigos predominantes puede pasar sin la aprobación de la mayoría
de los testigos actuales. Se recomienda que los testigos y los posibles testigos declaren públicamente
su política de lista de testigos (como seguir y promediar las listas de testigos de otros usuarios acreditados), y
que los usuarios evalúen su aptitud para el trabajo en función de esta política, entre otros factores. Cualquier
violación de
la política declarada será visible inmediatamente y probablemente desencadene una campaña de reemplazo
de testigos.
Lo mismo es cierto para una enmienda injustificada a la política. La política vincula al testigo y hace
él sigue la opinión pública, incluso cuando se vuelve contra el testigo mismo o sus amigos.
Como se mencionó anteriormente, nuestras reglas de protocolo requieren que:
1. El mejor padre se selecciona solo entre los padres cuya lista de testigos no tiene más de 1 mutación;
2. no debe haber más de 1 mutación relativa a la lista de testigos de la última unidad de pelota;
3. no debe haber más de 1 mutación relativa a las listas de testigos de todos los MC inestables
unidades hasta la última unidad de bola;
4. el punto de estabilidad avanza solo cuando los testigos actuales (como se define en la estabilidad actual)
punto) publicar suficientes unidades después del punto de estabilidad actual.
Estas reglas están diseñadas para proteger contra horquillas maliciosas y accidentales. Al mismo tiempo, ellos
implican que cualquier cambio en la lista de testigos predominantes tiene que ser gradual, y cada paso tiene
que ser
aprobado por la mayoría de los testigos actuales.
Un cambio de una posición primero tiene que alcanzar la estabilidad y el reconocimiento de la mayoría de los
viejos testigos antes
otro cambio puede ser emprendido. Si la comunidad decide abruptamente que dos testigos necesitan
para ser reemplazado inmediatamente, luego, después de que un cambio llega al MC, el segundo cambio
será bloqueado por la regla 3 anterior hasta que el primer cambio alcance la estabilidad.
A pesar de todas las recomendaciones anteriores, aún es posible que debido a la negligencia de los líderes de
la industria,
tales testigos son elegidos que más tarde forman un cartel y bloquean colectivamente todos los intentos de
reemplazar
cualquiera de ellos en un intento de mantener las ganancias que están obteniendo al presenciar comisiones.
Si
se comportan de esta manera, será evidente para todos porque sus listas de testigos se mantendrán sin
cambios,
mientras que las listas de testigos de la mayoría de los otros líderes de la industria diferirán en una mutación
(el máximo
permitido permanecer compatible). Si los viejos testigos no ceden a pesar de tanta presión evidente,
el único recurso de los usuarios a favor del cambio es una "revolución", es decir, comenzar una nueva
moneda que hereda
todos los saldos, direcciones de usuario, etc. de la moneda antigua en algún momento, pero comienza con
una nueva lista de testigos
y agrega una regla de protocolo especial para manejar este cambio incompatible en este momento
del cisma Para distinguir de la moneda antigua, asignarían un nuevo valor al campo 'alt'
(para esto sirve 'alt') y úselo en todas las unidades emitidas con la nueva moneda. Como resultado, los
usuarios tendrán dos
monedas (la antigua alt = "1", y la nueva, por ejemplo, alt = "2") y podrá gastar ambas de forma
independiente. Si el
la división se justificó, la moneda vieja probablemente se abandonará, pero todos los datos acumulados
antes de la
el cisma estará disponible como normal en la nueva moneda. Dado que el protocolo es casi idéntico (a
excepción de
la regla que maneja el cisma y el cambio de alt), será fácil actualizar el software instalado en
todos los dispositivos de usuarios y comerciantes.
Si alguien solo quiere comenzar una nueva moneda para experimentar con otro conjunto de reglas de
protocolo, puede
también use el campo 'alt' para heredar todo de la moneda antigua, hacer que el interruptor sea cómodo
para los usuarios,
y tiene un gran conjunto de usuarios con saldos desde el primer día.
6.17 SKIPLIST
Algunas de las bolas contienen una matriz de skiplist que permite una compilación más rápida de pruebas
para clientes ligeros (ver
abajo). Solo aquellas bolas que se encuentran directamente en el MC, y cuyo índice MC es divisible por 10,
tienen un
skiplist. El skiplist enumera las bolas MC más cercanas cuyo índice tiene el mismo número o menor
de ceros al final. Por ejemplo, la pelota en MCI 190 tiene una lista de skiplist que hace referencia a la pelota
en MCI
180. El balón en MCI 3000 tiene una lista de skiplist que hace referencia a las bolas en los MCI 2990, 2900 y
2000.
6.18 CLIENTES DE LUZ
Los clientes ligeros no almacenan toda la base de datos de Byteball. En cambio, descargan un subconjunto de
datos que
están interesados, como solo las transacciones en las que alguna de las direcciones del usuario está gastando
o siendo
fundado.
33
Los clientes ligeros se conectan a nodos completos para descargar las unidades en las que están interesados.
El cliente ligero le dice
el nodo completo la lista de testigos en los que confía (no necesariamente los mismos testigos que usa para
crear nuevos
unidades) y la lista de sus propias direcciones.
El nodo completo busca las unidades en las que el cliente ligero está interesado y construye una cadena de
pruebas para cada
unidad de la siguiente manera:
1. Retroceda en el tiempo a lo largo del MC hasta que se cumplan la mayoría de los testigos solicitados.
Recoger todo
estas unidades de MC
2. Desde la última unidad de este conjunto (que también es la más antigua en el tiempo), lea la última bola.
3. Comenzando desde esta última bola, retroceda en el tiempo a lo largo del MC hasta que se encuentre
cualquier bola con una lista de skiplist.
Recoge todas estas bolas.
4. Usando la lista de skip, salta a una bola anterior a la que se hace referencia desde la lista de skiplists. Esta
pelota también tiene una lista de skippers,
saltar de nuevo. Donde hay varias bolas en la lista de skiplist, siempre salta por la distancia más grande
posible, así que aceleramos saltando primero por 10 índices, luego por 100, luego por 1000, etc.
5. Si el próximo salto por la lista de skiplist nos arrojara detrás de la bola objetivo, desacelere saltando
por una distancia menor. En última instancia, abandone la lista de reproducción y camine a lo largo del índice
de MC uno en una
tiempo usando solo enlaces padres.
Esta cadena tiene unidades autorizadas por testigos al comienzo, por lo que es confiable desde el cliente
ligero
punto de vista. Todos los elementos de la cadena están vinculados por enlaces de unidades de padres
(mientras se acumulan
los testigos), o por última referencia de pelota, o por enlaces de bola de padres, o por enlaces de skiplist. Al
final de
cadena, tenemos la unidad cuya existencia debía ser probada.
6.19 FIRMA MULTILATERAL
Una unidad puede ser firmada por varias partes. En tales casos, la matriz de autores en la unidad tiene dos o
mas elementos
Esto puede ser útil, por ejemplo. si dos o más partes quieren firmar un contrato (un simple contrato tonto,
no es inteligente). Ambos firmarían la misma unidad que contiene un mensaje de texto (app = 'text').
No tienen que almacenar el texto completo del contrato en la base de datos pública, y pagarlo - un hash
sería suficiente (ubicación_carga_carga = 'ninguno') y las partes mismas pueden almacenar el texto de forma
privada.
Otra aplicación de la firma multilateral es un intercambio de activos. Suponer que el usuario A quiere enviar
activos
X al usuario B a cambio del activo Y (la moneda nativa 'bytes' también es un activo, el activo base).
Luego compondrían una unidad que contiene dos mensajes de pago: un pago envía el activo X
de A a B, el otro pago envía el activo Y de B a A. Ambos firman la unidad de doble autor y
publícalo. El intercambio es atómico, es decir, ambos pagos se ejecutan al mismo tiempo o ambos
fallar. Si uno de los pagos parece ser un gasto doble, la unidad completa se invalida y el
otro pago también se considera nulo.
Esta simple construcción permite a los usuarios intercambiar activos directamente, sin confiar su dinero a
ningún
intercambios centralizados.
6.20 DIRECCIONES
Los usuarios se identifican por sus direcciones, los resultados de las transacciones se envían a direcciones y,
como en Bitcoin,
se recomienda que los usuarios tengan varias direcciones y eviten reutilizarlas. En algunas circunstancias,
sin embargo, la reutilización es normal. Por ejemplo, se espera que los testigos publiquen repetidamente
desde
misma dirección.
Una dirección representa una definición, que es una expresión booleana (remotamente similar al script de
Bitcoin).
Cuando un usuario firma una unidad, también proporciona un conjunto de autentificadores (generalmente
firmas ECDSA) que,
cuando se aplica a la definición, debe evaluarlo como verdadero para demostrar que este usuario tenía el
derecho para firmar esta unidad Escribimos definiciones en JSON. Por ejemplo, esta es la definición de una
dirección que requiere una firma ECDSA para firmar:
["sig",{"pubkey":"Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]
La definición indica que el propietario de la dirección tiene una clave privada cuya contraparte pública es
dado en la definición (en codificación base64), y firmará todas las unidades con esta clave privada. Lo anterior
la definición se evalúa como verdadera si la firma dada en el autenticador correspondiente es válida, o de
otra manera
falso. La firma se calcula sobre todos los datos de la unidad, excepto los autentificadores.
Dado un objeto de definición, la dirección correspondiente es solo un hash del objeto de definición inicial
más
una suma de comprobación. La suma de comprobación se agrega para evitar errores de tipeo. A diferencia de
los diseños de suma de comprobación habituales, sin embargo,
los bits de suma de comprobación no se añaden al final de los datos no verificados. Más bien, son
insertado en múltiples ubicaciones dentro de los datos. Este diseño hace que sea difícil insertar largas
cadenas de caracteres ilegales
datos en campos donde se espera una dirección. La dirección está escrita en codificación base32. Lo anterior
la definición corresponde a la dirección A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU.
Cuando se financia una dirección, el remitente del pago conoce y especifica solo la dirección (el
suma de comprobación hash de la definición) en el resultado de pago.
La definición no se revela y sigue siendo desconocida para nadie más que para el propietario hasta que la
salida sea
gastado.
Cuando un usuario envía su primera unidad desde una dirección, debe revelar su definición (para poder
firmar
verificación posible) en la matriz de autores:
Si el usuario envía una segunda unidad desde la misma dirección, debe omitir la definición (ya está
conocido en Byteball). Puede enviar la segunda unidad solo después de que la definición se estabilice, es
decir,
la unidad donde se reveló la definición debe incluirse en la última unidad de bola de la segunda unidad.
Los usuarios pueden actualizar las definiciones de sus direcciones manteniendo la dirección anterior. Por
ejemplo, para rotar
la clave privada vinculada a una dirección, el usuario debe publicar una unidad que contenga un mensaje
como:
Aquí, definition_chash indica el hash checksummed de la nueva definición de dirección (que no es
revelado hasta más tarde), y la unidad misma debe estar firmada por las antiguas claves privadas. La próxima
unidad de este
dirección debe:
• incluir esta unidad address_definition_change en su última unidad de bola, es decir, debe estar ya estable;
• revelar la nueva definición en la matriz de autores de la misma manera que para el primer mensaje de
Una dirección.
Después del cambio, la dirección ya no es igual al hash de suma de comprobación de su definición actual.
Por el contrario, permanece igual al hash de suma de comprobación de su definición inicial.
El cambio de definición es útil si el usuario desea cambiar la (s) clave (s) (por ejemplo, al migrar a un nuevo
dispositivo) mientras se mantiene la dirección anterior, p. si esta dirección ya participa en otras definiciones
de larga vida
(vea abajo).
6.20.1 Sintaxis de definición
6.20.1.1 Operadores lógicos
Una definición puede incluir condiciones "y", por ejemplo:
que es útil cuando, para firmar transacciones, se requieren firmas de dos dispositivos independientes,
por ejemplo, desde una computadora portátil y desde un teléfono inteligente.
"O" condiciones, como esta:
son útiles cuando un usuario quiere usar la misma dirección desde cualquiera de sus dispositivos.
Las condiciones se pueden anidar:
Una definición puede requerir un número mínimo de condiciones para ser verdadero de un conjunto más
grande, por ejemplo,
una firma de 2 de 3
("R" significa "requerido") que presenta tanto la seguridad de dos firmas obligatorias como la confiabilidad,
de modo que en caso de que se pierda una de las claves, la dirección aún pueda usarse y se pueda usar para
cambiar su
definición y reemplazar la tercera clave perdida con una nueva.
Además, diferentes condiciones pueden tener diferentes pesos, de los cuales se requiere un mínimo:
6.20.1.2 Delegación a otras direcciones
Una dirección puede contener referencia a otra dirección:
que delega la firma a otra dirección y es útil para construir direcciones de control compartidas (direcciones
controlado por varios usuarios). Esta sintaxis brinda a los usuarios la flexibilidad para cambiar las definiciones
de
sus propias direcciones de componente siempre que lo desean, sin molestar al otro usuario.
6.20.1.3 Firmas y autentificadores
En la mayoría de los casos, una definición incluirá al menos una firma (directa o indirectamente):
En lugar de una firma, una definición puede requerir una preimagen para que se proporcione un hash:
que puede ser útil para algoritmos de intercambio de cadenas cruzadas [7]. En este caso, se ingresa la
preimagen hash
como uno de los autentificadores.
37
El algoritmo de firma predeterminado es ECDSA en la curva secp256k1 (igual que Bitcoin). Inicialmente, es el
único
Algoritmo soportado. Si se agregan otros algoritmos en el futuro, se usará un identificador de algoritmo en
la parte correspondiente de la definición, como para el algoritmo NTRU de seguridad cuántica:
Las definiciones de firma múltiple permiten experimentar con seguridad con esquemas de firma no
comprobados cuando
se combinan con firmas más convencionales.
El objeto de autentificación en los encabezados de unidad contiene firmas u otros datos (como la preimagen
de hash)
codificado por la ruta de la subdefinición que requiere autenticación dentro de la definición de dirección.
Para un single-sig
dirección como
el camino es simplemente "r" (r significa raíz). Si la definición secundaria que requiere autenticación se
incluye dentro de
otra definición (como y / o), la ruta se extiende por un índice en la matriz donde esta subdefinición
está incluido, y los componentes de ruta están delimitados por un punto. Por ejemplo, para la definición de la
dirección:
los caminos son "r.0" y "r.1". Para una definición anidada más profunda:
las rutas son "r.0.0", "r.0.1" y "r.1". Cuando hay firmas opcionales, como 2 de 3, las rutas
díganos qué claves fueron realmente utilizadas.
6.20.1.4 Plantillas de definición
Una definición también puede hacer referencia a una plantilla de definición:
Los parámetros especifican los valores de las variables que se reemplazarán en la plantilla. La plantilla
necesita ser
guardado antes (y como de costumbre, manténgase estable antes del uso) con un tipo de mensaje especial
app = 'definition_template',
la plantilla en sí misma está en la carga útil del mensaje, y la plantilla parece una definición normal, pero
puede incluir referencias a variables en la sintaxis @ param1, @ param2. Las plantillas de definición habilitan
reutilización del código A su vez, pueden hacer referencia a otras plantillas.
38
6.20.1.5 Cosiderazgo
Una subdefinición puede requerir que la unidad sea firmada por otra dirección:
["cosigned by", "ANOTHER ADDRESS IN BASE32"]
6.20.1.6 Consultando si se utilizó una dirección
Otro posible requisito para una subdefinición: que una dirección se considerara como
autor en al menos una unidad incluida en la última unidad de bola:
["seen address", "ANOTHER ADDRESS IN BASE32"]
6.20.1.7 Feeds de datos
Una condición muy útil se puede usar para realizar consultas sobre datos previamente
almacenado en Byteball:
Esta condición se evalúa como verdadera si hay al menos un mensaje que tiene "nombre de fuente de datos"
igual a
"valor esperado" entre los mensajes de alimentación de datos creados por las direcciones listadas
"DIRECCIÓN1", "DIRECCIÓN2",
.. (oráculos). La fuente de datos es un tipo de mensaje que se ve así:
Los campos de datos se pueden usar para diseñar definiciones que involucran oráculos. Si dos o más partes
confían en un particular
entidad (el oráculo) para proporcionar datos verdaderos, pueden configurar una dirección de control
compartido que proporcione
partidos diferentes derechos dependiendo de los datos publicados por el oráculo (s). Por ejemplo, esta
definición de dirección
representa una opción binaria:
Inicialmente, las dos partes financian la dirección definida por esta definición (para eliminar cualquier
requisito de confianza,
utilizan la firma multilateral y envían sus participaciones en una sola unidad firmada por ambas partes).
Entonces, si la tasa de cambio EUR / USD publicada por la dirección de intercambio supera alguna vez 1.1500,
la primera
la parte puede barrer los fondos. Si esto no ocurre antes del 1 de octubre de 2016 y el oráculo de sellado de
tiempo
publica cualquier después
fecha, la segunda parte puede barrer todos los fondos almacenados en esta dirección. Si ambas condiciones
son verdaderas y el
el saldo de la dirección aún no está vacío, ambas partes pueden intentar tomar el dinero al mismo tiempo,
y el doble gasto se resolverá como de costumbre.
Los operadores de comparación pueden ser "=", "! =", ">", "> =", "<" Y "<=". El mensaje de alimentación de
datos debe
ven antes de la última unidad de pelota como de costumbre. Para reducir los riesgos que surgen en caso de
que un solo oráculo repentinamente
se desconecta, se pueden enumerar varias direcciones de proveedor de feed.
Otro ejemplo sería un cliente que compra bienes a un comerciante pero no confía del todo ese comerciante y
quiere recuperar su dinero en caso de que los bienes no se entregan. El cliente paga a un
dirección compartida definida por:
La definición depende del oráculo de FedEx que publica los números de seguimiento de todos los entregados
con éxito
envíos. Si el envío se entrega, el comerciante podrá desbloquear el dinero utilizando la primera
condición. Si no se entrega antes de la fecha especificada, el cliente puede recuperar su dinero.
Este ejemplo es un poco loco porque requiere que FedEx publique todos y cada uno de los envíos.
6.20.1.8 Feeds de datos de Merkle
Para una forma más realista de lograr el mismo objetivo, hay otra sintaxis:
que se evalúa como verdadero si el hash especificado del valor esperado se incluye en cualquiera de las
raíces de merkle
publicado en el feed de datos de las direcciones "ADDRESS1", "ADDRESS2", ... Con esta sintaxis, FedEx
solo publica periódicamente las raíces de merkle de todos los envíos completados desde la publicación
anterior. Gastar
desde esta dirección, el comerciante debería proporcionar la ruta de Merkle que demuestre que el
el valor está de hecho incluido en el árbol de merkle correspondiente. La ruta Merkle se suministra como una
de
los autentificadores
6.20.1.9 Autoinspección
Una definición también puede incluir consultas sobre la unidad en sí. Esta subdefinición
se evalúa como verdadero si la unidad tiene al menos una entrada o salida (dependiendo del campo 'qué')
que
pasa todos los filtros especificados, con todos los filtros siendo opcionales.
Una condición similar 'tiene uno' requiere que haya exactamente una entrada o salida que pase los filtros.
La condición 'has' se puede usar para organizar un intercambio descentralizado.
Anteriormente, discutimos el uso de la firma multilateral para intercambiar activos.
Sin embargo, la firma multilateral por sí sola no incluye ningún mecanismo para la negociación de precios.
Asumir
que un usuario quiere comprar 1,200 unidades de otro activo por el cual está dispuesto a pagar no más de
1,000 bytes. Además, no está dispuesto a permanecer en línea todo el tiempo mientras espera a un
vendedor. Él haría
en lugar de simplemente publicar un pedido en un intercambio y dejar que se ejecute cuando aparezca un
vendedor coincidente. Él
puede crear una orden de límite enviando 1,000 bytes a una dirección definida por esta definición:
La primera o alternativa permite al usuario recuperar sus bytes cuando lo desee, cancelando así el pedido.
La segunda alternativa delega el intercambio el derecho a gastar los fondos, siempre que otro
la salida en la misma unidad paga al menos 1,200 unidades del otro activo a la dirección del usuario. El
intercambio
haría una lista pública del pedido, un vendedor lo encontraría, componería una unidad que intercambiara
activos, y
firmarlo multilateralmente con el intercambio.
También se puede usar la condición 'has' para préstamos garantizados. Supongamos que un prestatario tiene
algo de ilíquido
activo y necesita algunos bytes (u otro activo líquido).
El prestatario y el prestamista pueden entonces firmar una unidad multilateralmente. Una parte de la unidad
envía los bytes que él
necesita al prestatario, la otra parte de la unidad bloquea el activo ilíquido en una dirección definida por:
La primera o alternativa le permite al prestamista tomar la garantía si el préstamo no se devuelve a tiempo.
La segunda alternativa permite al prestatario recuperar la garantía si también realiza un pago de
10,000 bytes (el tamaño del préstamo acordado, incluidos los intereses) para el prestamista. La tercera
alternativa permite
partes para enmendar los términos si ambos están de acuerdo.
El siguiente requisito también se puede incluir en una subdefinición:
Se evalúa como verdadero si hay al menos un par de entradas o salidas que satisfacen los criterios de
búsqueda (el
primer elemento del par se busca por el primer conjunto de filtros, el segundo por el segundo) y algunos de
sus campos son iguales.
Una condición similar "tiene una igual" requiere que exista exactamente uno de esos pares.
Otra subdefinición puede comparar la suma de entradas o salidas filtradas según ciertos criterios
a un valor o valores objetivo:
6.20.1.10 Negación
Cualquier condición que no incluya "sig", "hash", "address", "coigned by", o "in"
merkle "puede ser negado:
Dado que es legal seleccionar padres muy viejos (que no vieron las publicaciones de feed de datos más
recientes), uno generalmente
combina condiciones negativas como las anteriores con el requisito de que la marca de tiempo sea posterior
a una
cierta fecha.
6.20.1.11 Requisitos generales
La definición de dirección debe tener al menos un "sig", explícita o implícitamente (como a través de una
"dirección").
Para evitar consumir demasiados recursos para la validación, el número total de operaciones se limita a
100 por definición, incluidas las operaciones en las definiciones a las que se hace referencia, como
"dirección" y "definición"
modelo".
Este número es uno de solo 9 constantes arbitrarias que tenemos en Byteball, las otras 8 son: total
número de testigos: 12; max mutaciones permitidas: 1; número máximo de índices MC para que un testigo
obtenga
43
pagado: 100; número de padres contados para el tamaño del encabezado: 2; número máximo de mensajes
por unidad: 128; máximo
número de entradas o salidas por mensaje: 128; número máximo de autores por unidad: 16; y dinero total
suministro: 1015. Para comparación, Bitcoin tiene al menos 17 constantes [8], mientras que Ethereum define
30 constantes
solo para el cronograma de tarifas [9].
Tenga en cuenta que el lenguaje de definición descrito anteriormente es declarativo y consiste
completamente en Boolean
declaraciones, lo que lo acerca al lenguaje de los contratos legales convencionales. Sin embargo, en términos
de
su poder expresivo, el lenguaje no se acerca al lenguaje de contratos inteligentes de Ethereum.
De hecho, ni siquiera permite escribir un trivial programa 'Hola mundo'. Este no era nuestro
Gol.
El lenguaje de definición Byteball no fue diseñado para ser exhaustivo; más bien, está diseñado para ser
comprensible para la mayor cantidad posible de personas, que no son necesariamente programadores. Sus
La sintaxis directa permite a todos interpretar y componer definiciones simples sin la ayuda
de un desarrollador (un "abogado" para la era de los contratos inteligentes), y se minimizan las posibilidades
de errores.
6.20.1.12 Activos
Hemos diseñado una base de datos que permite el almacenamiento inmutable de cualquier información. De
todas las clases de datos, el
Lo más interesante para el almacenamiento en una base de datos común son los que tienen valor social, es
decir, los datos que
es valioso para más de uno o dos usuarios.
Una de esas clases es activos. Los activos pueden ser propiedad de cualquiera entre un gran número de
personas, y el
propiedades de inmutabilidad y ordenamiento total de eventos que tenemos en Byteball son muy
importantes
para establecer la validez de las largas cadenas de transferencias de propiedad. Los activos en Byteball
pueden ser emitidos,
transferidos, e intercambiados, y se comportan de manera similar a los 'bytes' de la moneda nativa. Ellos
pueden representar
cualquier cosa que tenga valor, por ejemplo, deuda, acciones, puntos de fidelidad, minutos de tiempo aire,
productos básicos,
otras monedas Fiat o Crypto.
Para definir un nuevo activo, el usuario que lo define envía un mensaje como este:
Aquí:
• límite es la cantidad máxima que se puede emitir. Para comparación con el nativo predefinido
bytes de moneda, el límite de bytes es 1015;
• is_private indica si el activo se transfiere de manera privada o pública (ver a continuación). Los bytes son
públicos;
• is_transferrable indica si el activo se puede transferir entre terceros sin pasar
a través del definidor del activo. Si no es transferible, el definidor debe ser siempre
el único emisor o el único receptor de cada transferencia. Los bytes son transferibles;
• auto_destroy indica si el activo se destruye cuando se envía al definidor. Los bytes no son
autodestruido;
• fixed_denominations indica si el activo puede enviarse en cualquier cantidad entera (arbitraria
importes) o solo en denominaciones fijas (por ejemplo, 1, 2, 5, 10, 20, etc.), que es el caso del papel
moneda y monedas. Los bytes están en cantidades arbitrarias;
• issued_by_definer_only indica si el activo solo puede ser emitido por un definidor. Para bytes, toda la
el suministro de dinero se emite en la unidad de génesis;
• cosigned_by_definer indica si cada transferencia debe ser coimada por el definidor del activo.
Esto es útil para activos regulados. Las transferencias en bytes no necesitan ser coimadas por nadie;
• spender_attested indica si el gastador tiene que ser atestiguado para gastar. Si sucedió
para recibir el activo, pero aún no está certificado, tiene que pasar la certificación con uno de los
atestiguadores listados bajo la definición, para poder gastar. Este requisito también es
útil para activos regulados. Los bytes no requieren certificación;
45
• attestors es la lista de direcciones de certificación reconocidas por el definidor de activos (solo si
spender_attestó
es verdad). La lista puede ser modificada posteriormente por el definidor enviando un 'asset_attestors'
mensaje que reemplaza la lista de atestiguadores;
• denominaciones (no se muestran en este ejemplo y se usan solo para activos de definiciones fijas)
enumera todas las denominaciones permitidas y el número total de monedas de cada denominación que
pueden ser
emitido;
• condición_transferencia es una definición de una condición cuando se permite la transferencia del activo.
La definición está en el mismo idioma que la definición de dirección, excepto que no puede hacer referencia
cualquier cosa que requiera un autentificador, como "sig". Por defecto, no hay restricciones
aparte de aquellos ya definidos por otros campos;
• issue_condition es lo mismo que transfer_condition pero para transacciones de emisión.
No puede haber más de 1 mensaje de 'activo' por unidad. Después de que se define el activo, es identificado
por el
hash de la unidad donde se definió (de ahí el requisito de 1 activo por unidad).
Una transferencia de un activo parece una transferencia de bytes, con la diferencia de que hay un campo
adicional para
la identificación del activo:
Antes de que se pueda transferir, se crea un activo cuando un usuario envía una transacción de emisión.
Emitir transacciones
tener un formato ligeramente diferente para las entradas:
El suministro completo de los activos de cantidades arbitrarias limitadas debe emitirse en una sola
transacción. En particular,
todos los bytes se emiten en la unidad de génesis. Si el activo tiene un límite, el número de serie del
problema
debe ser 1. Si no tiene un tope, los números de serie de los diferentes números por la misma dirección deben
ser
único.
Un activo se define solo una vez y no se puede modificar posteriormente, solo la lista de certificadores puede
ser
enmendado.
Depende del definidor del activo lo que este activo representa. Si es la deuda del emisor, es razonable
esperar que el emisor esté atestiguado o renuncie a su anonimato para ganarse la confianza de los
acreedores.
Mientras que los usuarios finales son libres de usar o no usar un activo, los definidores de activos pueden
imponer cualquier requisito
en las transacciones que involucran el activo.
47
Al combinar varias propiedades de activos, el definidor puede diseñar activos que satisfagan una amplia
gama de requisitos,
incluidos aquellos que las instituciones financieras reguladas deben seguir. Por ejemplo, al requerir
que cada transferencia sea firmada por el definidor, las instituciones financieras pueden vetar efectivamente
a todos
pagos que contradicen cualquier regulación o regulación contractual. Antes de firmar cada pago, el
institución financiera (que también es el definidor y el emisor) verificaría que el usuario sea realmente su
cliente, que el destinatario de los fondos es también un cliente, que ambos clientes han pasado todo el Know
Your
Los procedimientos del cliente (KYC), que cambian constantemente las leyes, regulaciones y reglas internas,
incluyendo
aquellos que se introdujeron después de que se definió el activo.
6.21 MENSAJERÍA PRIVADA Para que los pagos privados funcionen, los usuarios necesitan una forma segura
de entregar cargas privadas entre sí.
Los usuarios, o más bien sus dispositivos, también necesitan comunicarse para ensamblar firmas para
direcciones multi-sig.
Dado que no podemos esperar que los dispositivos de los usuarios estén constantemente en línea y sean
fácilmente accesibles (la mayoría de ellos
estar detrás de NAT), necesitamos un intermediario de almacenamiento y envío que esté siempre en línea,
sea fácilmente accesible,
y capaz de almacenar temporalmente cualquier información dirigida a un dispositivo de usuario.
En Byteball, dicho intermediario se denomina centro y su funcionamiento es similar al correo electrónico. Un
centro es una
Nodo de byteball que además ofrece un servicio de almacenamiento y reenvío de mensajes privados a
conectado
dispositivos. Puede haber muchos centros. Cada dispositivo que ejecuta un código de billetera se suscribe a
un centro de
su elección, y se puede llegar a través de este centro (el centro de inicio). La elección del hub de inicio se
puede cambiar
en cualquier momento.
Cada dispositivo tiene una clave privada permanente que es exclusiva del dispositivo. El hash de la
correspondiente
clave pública (más precisamente, el hash de la definición single-sig basada en esta clave pública) se llama
dirección del dispositivo, y está escrito en base32 como las direcciones de pago. La dirección completa del
dispositivo, incluido
su hub actual, se puede escribir como [email protected]. Si el
el dispositivo se mueve a otro concentrador, la parte de su dirección completa antes @ se mantiene igual. A
diferencia del correo electrónico, el
nombre no puede ser "tomado".
Cada dispositivo se conecta a su hub de origen usando websockets. El concentrador envía los mensajes
nuevos al
dispositivo y el dispositivo permanece conectado al concentrador, de modo que si llega un mensaje nuevo
mientras el dispositivo está
conectado el nuevo mensaje se entrega de inmediato. El concentrador no guarda copias de los mensajes
que fueron aceptados con éxito por el dispositivo. La conexión al concentrador está encriptada con TLS.
Cuando un dispositivo desea enviar algo a otro dispositivo, se conecta al concentrador del destinatario y
envía el mensaje A diferencia del correo electrónico, no hay retransmisión: el remitente se conecta
directamente con el destinatario.
cubo. Toda la comunicación entre dispositivos está encriptada de extremo a extremo y firmada digitalmente
de modo que incluso
el centro (que es el único hombre en el medio) no puede verlo o modificarlo. Usamos ECDSA para firmar y
ECDH + AES para el cifrado.
Antes de intercambiar mensajes cifrados, los dispositivos deben estar emparejados, es decir, aprender la
clave pública de los demás.
Esto puede suceder de varias maneras, p. escaneando un código QR que codifica la clave pública y el dominio
del concentrador
nombre de uno de los dispositivos, enviando esta información por correo electrónico o haciendo clic en un
byteball: //
enlace en un sitio web seguro.
Para la seguridad directa, cada dispositivo genera una clave privada temporal y carga la correspondiente
clave pública para su hub de origen. Después, el dispositivo gira la tecla de vez en cuando pero mantiene un
48
copia de la clave anterior en caso de que alguien haya enviado un mensaje a la clave anterior mientras el hub
estaba reemplazando
eso. El concentrador mantiene solo una versión de la clave pública temporal por dispositivo suscrito.
El dispositivo de envío sigue estos pasos para enviar un mensaje:
1. se conecta al centro del destinatario;
2. recibe la clave pública temporal actual del destinatario desde el centro;
3. genera su propio par de claves efímeras de una sola vez;
4. deriva el secreto compartido de ECDH de la clave pública temporal del destinatario y el propio efímero
llave privada;
5. AES: encripta el mensaje usando este secreto compartido;
6. agrega su propia clave pública efímera;
7. firma el paquete con su propia clave permanente; y
8. lo envía al centro.
El dispositivo receptor verifica la firma, deriva el secreto de ECDH usando el público efímero del par
clave y propia clave privada temporal, y descifra el mensaje.
Si el dispositivo que envía no puede conectarse al concentrador del destinatario, cifra el mensaje en el
destinatario
clave permanente (este cifrado no es seguro hacia adelante ya que utiliza una clave permanente) y almacena
el
mensaje encriptado localmente para futuros intentos. El propósito de este cifrado es evitar tener descifrado
mensajes por ahí. Después de que la conexión al concentrador del destinatario tiene éxito, el dispositivo
envía
este mensaje cifrado, por lo tanto, encriptarlo de nuevo (esta vez, con seguridad hacia adelante), por lo que
el mensaje es
doble cifrado. Tenga en cuenta que esto no se debe a que el cifrado individual es insuficiente, sino porque
no desea almacenar contenido no encriptado por un tiempo indefinido mientras se vuelven a intentar las
conexiones.
Tenga en cuenta que la comunicación es entre dispositivos, no usuarios. Los usuarios pueden (y se les
recomienda)
sostenga varios dispositivos, como una computadora portátil, un teléfono inteligente y una tableta, y
configure varias direcciones multisig con
redundancia (como 2 de 3) que dependen de las claves almacenadas en varios dispositivos. Cuando un
usuario necesita
firmar una transacción, la inicia en uno de sus dispositivos. Este dispositivo luego envía el mensaje
parcialmente firmado
transacción a los otros dispositivos que utilizan mensajes privados, recopila todas las firmas y publica el
transacción. Las claves privadas almacenadas en cada dispositivo nunca deberían salir de ese dispositivo.
Cuando el usuario
reemplaza uno de sus dispositivos en una dirección de 2 de 3, solo usa los otros 2 dispositivos para cambiar la
dirección
definición y reemplazar la clave del dispositivo antiguo con la clave de un nuevo dispositivo.
Los mensajes privados también se pueden usar para enviar mensajes de texto cifrados entre dispositivos.
Estos mensajes son
estrictamente de igual a igual, nunca ingrese a la base de datos de Byteball, y puede descartarse de manera
segura después de que son
leer.
Cuando los usuarios pagan en blackbytes u otros activos privados, tienen que enviar cargas privadas y
absolutamente
Necesito dispositivos que puedan comunicarse. Necesitan conocer las direcciones de los dispositivos de los
demás antes
incluso aprenden las direcciones de pago de los demás. Una vez que sus dispositivos hayan establecido
comunicación,
el beneficiario puede enviar su dirección de pago al pagador a través del mensaje de chat. Tal escenario de
pago
también hace que sea fácil generar una dirección de pago única para cada entrada
pago. Un comerciante puede ejecutar un bot de chat que se comunica con los usuarios a través de mensajes
de texto. Cuando el
el usuario está listo para pagar, el bot genera una nueva dirección de pago y la envía al usuario en un
mensaje de chat.
49
6.22CONCLUSIÓN Hemos propuesto un sistema de almacenamiento inmutable descentralizado de datos
arbitrarios, incluidos datos de
valor social como el dinero. Cada nueva unidad de datos confirma implícitamente la existencia de todos los
anteriores
unidades. La revisión de registros anteriores similar a la de 1984 se vuelve imposible, ya que cada nueva
unidad también implícitamente
protege todas las unidades previas de la modificación y eliminación. Hay una moneda interna que es
utilizado para pagar la inclusión de datos en la base de datos descentralizada. El pago es igual al tamaño de
los datos que se almacenarán, y aparte de este pago, no hay restricciones de acceso a la base de datos.
También se pueden emitir otros activos y su propiedad se puede rastrear en la base de datos.
Al rastrear pagos en la moneda interna y otros activos, los gastos dobles se resuelven por
elegir la versión de la historia que fue presenciada por usuarios reconocidos. La finalidad del acuerdo es
determinista Los activos se pueden emitir con cualquier regla que rija su transferibilidad, permitiendo
regulaciones
instituciones para emitir activos que cumplan con los requisitos reglamentarios. Al mismo tiempo, las
transferencias pueden ser
oculto a terceros enviando su contenido de forma privada, directamente desde el pagador al beneficiario y
publicando
gaste pruebas para asegurarse de que cada moneda se gaste solo una vez.
7 REFERENCES
Official homepage of Dagcoin
https://dagcoin.org
Independence of cyberspace
https://www.eff.org/cyberspace-independence
Bitcoin whitepaper
https://bitcoin.org/bitcoin.pdf
Byteball whitepaper
https://byteball.org/Byteball.pdf
Issuing assets on Byteball network
https://github.com/byteball/byteballcore/wiki/Issuing-assets-on-Byteball
Quoted from Wikipedia
https://en.wikipedia.org/wiki/Nineteen_Eighty-Four
Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System
https://bitcoin.org/bitcoin.pdf - 2008
Sergio Demian Lerner. DagCoin
https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf - 2015
Serguei Popov. The Tangle
http://iotatoken.com/IOTA_Whitepaper.pdf - 2016
TomHolden. Transaction Directed Acyclic Graphs
https://bitcointalk.org/index.php?topic=1504649.0 - 2016
Linked timestamping
https://en.wikipedia.org/wiki/Linked_timestamping
Atomic cross-chain trading
https://en.bitcoin.it/wiki/Atomic_crosschain_trading
https://github.com/bitcoin/bitcoin
Gavin Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger
http://gavwood.com/Paper.pdf
