Esta presentación: slides.cuban.tech/skycoin.intro.html
SSID: cubantech
Contraseña: meet-ups
- Máquinas de estado replicadas (RSM por sus siglas en Inglés)
- Infraestructura, herramientas de gestión y administración
- Relación entre RSM y Blockchain
- Reglas de ejecución y consenso
- Teoría General de las DApps
- Introducción a Skycoin
Notas intercaladas sobre Skycoin, Bitcoin, y Ethereum
--
- ¿Por qué Skycoin?
- Comprendiendo las transacciones de Skycoin
- Valores principales
- Cinco pilares de Skycoin
- Ecosistema Skycoin
- ¿Próximos pasos?
Responda aquí
- Lenguaje de programación Go
- Blockchain
- Aplicaciones distribuidas
- Criptografía asimétrica y criptomonedas
- Contabilidad y finanzas
- Bitcoin, Ethereum, Skycoin
--
--
--
- Tolerancia de fallas más allá de los procesadores de un solo nodo
- Réplicas de un mismo servidor ejecutadas en procesadores independientes
- Protocolos para la interacción de los clientes con las réplicas
- Aislamiento físico y eléctrico para fallas de servidores independientes
--
- Vamos a asumir que serán máquinas de estado determinísticas
- ... incluso si pueden ser Turing completas
- Desplegar réplicas del software
- Recibir solicitudes de los clientes (i.e. entradas)
- Ordenar las entradas
- Ejecutar indefinidamente la transición de la máquina de estado
- Monitorear diferencias en el Estado o las Salidas de las réplicas
| |
 |
 |
| go | C / C++ | go |
| Skycoin @ Github | Bitcoin @ Github | Ethereum @ Github |
| Ethers.io @ Github |
--
| |
 |
| bitcoind @ Debian | Repo apt de Blockstack |
--
- Contenedores y registros
- p.e. Skycoin, Lisk, Blockstack, ... @ Docker Hub
- Herramientas de gestión de configuración (Ansible, Puppet, Chef, Habitat, ...)
--
- Desplegar réplicas del software
- Recibir solicitudes de los clientes (entiéndase entradas)
- Ordenar las entradas
- Ejecutar indefinidamente la transición de la máquina de estado
- Monitorear las réplicas buscando diferencias en el Estado o la Salida
- Múltiples soluciones
- p.e. Transacciones
- Todas las transacciones/objetos pertenecen a una única clave pública
- Se complica el diseño
- Se compromete la privacidad
- Cuentas fácilmente rastreables y monitoreables
Modelos de transacciones - Salida de transacciones no consumida (UTXO por sus siglas en Inglés) de Bitcoin
--
Metadatos importantes (excepto transacciones coinbase)
- ID (global) de transacción
- Número de versión (evolución del protocolo)
- Locktime
- Momento más inmediato en que la transacción puede ser agregada a la blockchain
- Las transacciones fijadas en el tiempo solo son válidas en el futuro
- Cancelaciones
--
- Salida(s) : Índice de arreglo implícito
- Monto (satoshis)
- Script de Pubkey ( Desbloquear para consumir )
- Entrada(s)
- Salida consumida (ID de transacción + Índice de salida)
- Número de secuencia (relacionado con el locktime)
- Script de firma (parámetros para desbloquear el script de Pubkey)
Bitcoin es un registro público distribuido.
--
blocktrail.com
--
- Curva (elíptica) ECDSA secp256k1
- Generación de clave (hash) pública determinística
--
- Hash de script para redimir en lugar de hash de clave pública
- Soporta los opcodes de los scripts de PubKey
--
- El remitente crea la UTXO con el script de PubKey
- ... usando el hash de la clave pública del receptor
- El remitente hace la difusión de la transacción (Red P2P)
- Los minadores la agregan a un bloque (... detalles más adelante ...)
- Billetera : monto UTXO como balance disponible
--
- Localización del ID de transacción y el índice para la UTXO
- Remitente crea la entrada para la transacción y agrega además:
- Número de secuencia
- Firma y PubKey (parámetros del script)
--
- Localización del ID de transacción y el índice para la UTXO
- Remitente crea la entrada para la transacción y agrega además:
- Número de secuencia
- Firma y PubKey (parámetros del script)
--
- Remitente prepara la UTXO para el receptor (como ya vimos)
- Remitente hace la difusión de la transacción (Red P2P)
- Los minadores la agregan a un bloque
- Validación del script ! ( A-ha! )
- Billetera : Actualiza el balance
--
- Almacenar los objetos UX como parte de la transacción
- referenciados por índice
- propician ataques de agotamiento de recursos
- Seguridad y privacidad demasiado complicadas
- p.e. generación de una nueva dirección para cada transacción
- IDs de hash independientes para UX y TX
- Objetos UX independientes de los objetos TX
- Diseño más simple
- Sin scripts
--
- Grafo bipartito acíclico dirigido simple de UX/TX
Monstruo muy peculiar
--
;; SECCIÓN DE PETICIÓN
;seed.bitcoin.sipa.be IN A
;; SECCIÓN DE RESPUESTA
seed.bitcoin.sipa.be. 60 IN A 192.0.2.113
seed.bitcoin.sipa.be. 60 IN A 198.51.100.231
seed.bitcoin.sipa.be. 60 IN A 203.0.113.183
- Conexión al puerto
8333(mainnet) o18333(testnet) - Seguido de mensajes
addranunciando las direcciones de los pares
--
- Envío del mensaje
version- número de versión local, bloque y fecha actual
- Par responde con su propio mensaje
version - Envío de
getaddry recepción deaddrde los nuevos pares (descubrimiento)
--
- Envío del mensaje
inva un par. - Espera del mensaje
getdata - Envío de la información de la transacción en el mensaje
tx - Par reenvía las transacciones a otros pares
- Nodos completos mantienen la lista de transacciones no confirmadas en un fondo de memoria
... continuará ...
- Sin DNS durante el descubrimiento P2P
- Desplegar réplicas del software
- Recibir solicitudes de los clientes (entiéndase entradas)
- Ordenar las entradas
- Ejecutar indefinidamente la transición de la máquina de estado
- Monitorear las réplicas buscando diferencias en el Estado o la Salida
- Múltiples soluciones
- Blockchain ?
- Transacciones Bitcoin !
--
Ordenamiento casual : Cadena de propiedad
- Desplegar réplicas del software
- Recibir solicitudes de los clientes (entiéndase entradas)
- Ordenar las entradas
- Ejecutar indefinidamente la transición de la máquina de estado
- Monitorear las réplicas buscando diferencias en el Estado o la Salida
- Ejecutar las entradas en cada réplica en el orden seleccionado
- Registro público
- Transacciones ordenadas y fechadas
- Almacenamiento distibuido en los nodos completos de Bitcoin
- Protección contra
- doble gasto
- modificación de los registros de transacciones previas
--
--
- Version : 4 bytes
- Previous block header hash : 32 bytes
- Merkle root hash : 32 bytes
- Time : 4 bytes
- nBits : 4 bytes
- nonce : 4 bytes
--
blocktrail.com
--
La transacción coinbase va primero
- Métricas
- Probar el interés legítimo, la irreversibilidad
- Tomarr desiciones respecto a los cambios en la DApp
- Más difícil modificar bloques pasados que agregar nuevos
- Ejemplos comunes
- Prueba de trabajo (Proof of work - PoW) : BTC
- Prueba de participación (Proof of stake - PoS)
- Prueba de quemado (Proof of burn) : SKY
- Prueba de colaboración (Proof of collaboration - PoC)
- Prueba de espacio (Proof of space - PoSpace), replicación** (PoR)
- Pueden ser usadas en paralelo
- p.e. PeerCoin utiliza PoW + PoS
--
- Mecanismo : Cantidad de trabajo computacional (CPU, GPU, NPU, ...) que contibuyó a la operación de la DApp
- Uso intensivo de recursos (energía, enfriamiento, ...)
- El mecanismo para establecer consenso a través de POW es llamado comúnmente minado
Bitcoin utiliza ese método para su operación diaria.
--
- Mecanismo : nuevas monedas de acuerdo a la cantidad de monedas (participación) que usted posee
- Aquellos que posean monedas suficientes pueden abusar de este mecanismo
- A menudo combinado con otra prueba
OmniLayer se basa en el mecanismo POS.
--
- Mecanismo : asignación de cantidades no triviales de memoria o almacenamiento necesarios para resolver un desafío (funciones intensivas de memoria - memory-hard)
- Alternativa más ecológica que PoW
PoStorage es usado en PermaCoin, SpaceMint, BurstCoin
--
- Nodos de Validación Colaborativa (CVNs por sus siglas en Inglés)
- Decidir que nodo creará el próximo bloque
- Aprobar los Nodos de Validación Colaborativa firmando digitalmente una porción de datos que contiene el ID del seleccionado
- Teniendo las firmas requeridas, obtener la TX y crear el nuevo bloque
- Sin recompensa (dinero nuevo) por la creación del bloque (pequeño costo)
- Bajo consumo de energía (CVNs pueden ejecutarse en una Raspberry3)
FairCoin (derivado de Bitcoin 0.12) implementa PoC desde el 18 de Julio de 2017
Modos de operación : Clientes de Verificación Simplificada de Pagos - SPV por sus siglas en Inglés vs nodo completo
- Primera ejecución : El nodo contiene solo el bloque 0
- Selección del par remoto (entiéndase nodo de sincronización)
- Descargar desde el bloque 1 hasta la punta actual de la mejor blockchain del nodo de sincronización
- Primero los bloques (hasta la versión 0.9.3)
- Primero las cabeceras (a partir de 0.10.0 en adelante)
- Agregar nuevos bloques a la block chain
- Hacer que el historial de transacciones sea difícil de modificar
- Estrategias
- Minería en solitario
- Minería mediante fondos
- Minador genera los nuevos bloques el mismo
- Reclama completamente la recompensa de bloque y los costos de transacción
- Pagos grandes
- Mayor varianza (mayor tiempo entre ellos)
- Grupo de minadores agregan los recursos al fondo junto con otros minadores
- Encuentro de bloques más a menudo y a destinos de bits más sencillos
- Procedimientos compartidos entre minadores
- Correlacionado con la PoW de potencia relativa de hash
- Pagos pequeños
- Menor varianza (entiéndase menor tiempo entre pagos)
--
Monedas emitidas : +1M BTC minados desde Diciembre de 2010. ZCASH desde 20 de Abril de 2017
--
--
--
Monedas emitidas : BTC
--
--
Monedas emitidas : BTC
- 6.4 EHash/s , 80,704,290.84 PFLOPS
- 10,000 toneladas métricas de hardware. Suficiente material para construir otra torre Eiffel.
--
Circuitos integrados de aplicación específica, ASICs por sus siglas en Inglés
--
... según BitcoinEnergyConsumption.com
- Proyectado que sea comparable con el consumo de Dinamarca en 2020
- Minador incluye el bloque minado en el nuevo mensaje
block - Minador envía el mensaje a sus pares nodos completos
desde la versióno 0.12.0
--
- Método estándar
- Minador envía mensaje
inva todo los pares (SPV y nodos completos)- Incluye inventario que referencia al bloque
- par BF ⇒
getdatapidiendo el bloque completo- Minador ⇒ mensaje
block
- Minador ⇒ mensaje
- par HF ⇒
getheaders(pocas cabeceras en la mejor blockchain)- Minador ⇒ mensaje
headers
- Minador ⇒ mensaje
- clientes SPV ⇒
getdatapidiendo un bloque Merkle- Minador ⇒
merkleblockseguido de varios mensajestx
- Minador ⇒
desde la versión 0.12.0
--
- Usado si el par envía la señal
sendheadersdurante el handshake - Minador envía el mensaje
headerspara el nuevo bloque - par HF ⇒ Validación parcial y envía
getdata - Minador ⇒
blockormerkleblock
desde la versión 0.12.0
- Problemas con la Prueba de Trabajo (Proof of Work)
- Prueba de Participación (Proof of Stake): Más problemas de centralización
- Mejoras técnicas
- Problemas de seguridad asociados con otras redes de blockchain
- Desacoplar la creación de monedas del proceso de minado
- Confirmación rápida de las transacciones
- Políticas inflacionistas
- El suministro de Skycoin es fijo
--
- Control de la red => poder económico
- Monopolización del minado
- Incentivación a la compra de potencia de hash
- Control desproporcionado sobre la red
- Bitcoin => SlushPool , Bitmain , BTCC
- Revertir y falsificar transascciones - ataque 51%
- Costo económico y ambiental
--
- Costos de transacción e inflación que desangran a los usuarios
- Más de $50, y a los fondos centralizados de minado
- Más costoso que transferencias bancarias internacionales
- Propicia ataques
- Agotamiento de recursos
- RAM y espacio en disco
- UX consumida fácil de remover
- No hay minado, no hay costo (no hay minado, no hay costo ...)
- Prueba de quemado - Horas de moneda
--
- Retener Skycoin en una billetera
- ... automáticamente genera Horas de Moneda
- 1 SKY * 1 hora = 1 Hora de Moneda.
- Mantener la red Skywire libre de costos de transacción
- Los juegos de gato virtual no pueden disparar los costos de transacción al 1600%
- Problema reciente en la red Ethereum
- Usuarios nunca pagan para acceder y usar la red
--
- ... las Horas de Moneda se inflan dramáticamente
- Máx = 100 millones de Horas de Moneda por hora
- Será alcanzado en décadas
- ... nunca ocurrieran transacciones en la red
- máx de Horas de Moneda no excederá
uint64por siglos.
- máx de Horas de Moneda no excederá
--
--
--
- Desplegar réplicas del software
- Recibir solicitudes de los clientes (entiéndase entradas)
- Ordenar las entradas
- Ejecutar indefinidamente la transición de la máquina de estado
- Monitorear las réplicas buscando diferencias en el Estado o la Salida
- Cada réplica genera salida
- Las réplicas sin errores producirán siempre la misma salida
- Las salidas con errores son filtradas
- Consenso
- La salida correcta es enviada al cliente
--
- Bloques simultáneos minados, nodos seleccionan el ganador
- Pares prefieren derivaciones con PoW más fuerte
- derivación más larga
- mayor alto de bloque : distancia hasta el bloque 0
--
- ¿ Cuándo ?
--
- Eliminar bloques (obsoletos y huérfanos) en derivaciones de baja PoW
- Iterar sobre las transacciones en bloques obsoletos y huérfanos
- descartarlas si la transacción pertenece a otro bloque de PoW de derivación más alta
- de lo contrario moverla de regreso al fondo de memoria de transacciones
- para ser incluida por este minador en un bloque futuro
- (¿opcionalmente?) difundirla a la red P2P
--
- ¿Cuándo?
- Extender la blockchain para prevenir el ataque del 51% de terceros
- Consenso mejorado acepta bloques anteriormente rechazados
- Partición de la red
--
- Advertencia en
getnetworkinfoy ejecución del comando-alertnotifysi estaba establecida- PoW de +6 bloques que la mejor chain válida
- Repetición del bloque y la transacción con números de versión más altos que el consenso esperado
- Transacción coinbase puede ser consumida solo después de 100 bloques
- Clientes SPV pueden contactar varios nodos completos
- descartar chains con PoW más débil
Software de billetera : Adicionar las UTXO para determinar balance
- Tolerancia a F fallas aleatorias independientes
- errores de memoria, roturas de discos duros, ...
- Requiere
2F + 1réplicas
- Réplica fallada puede detenerse sin generar salidas
- Solo se requieren
F + 1réplicas - ... ningún sistema existente alcanza este límite
- Solo se requieren
- Fallas Bizantinas
- fallas aleatorias, espurias ⇒
2F + 1 - ataques maliciosos, inteligentes ⇒
3F + 1
- fallas aleatorias, espurias ⇒
--
- Computadora de escritorio o portátil (Windows, Mac OS X, o Linux)
- 125 GB de espacio en disco, 2 GB RAM
- Internet de Banda Ancha con subida ≥ 400 Kbps (50 KB/s)
- Conexión no metrada, o límites altos de subida, respeto a los límites de subida
- +100 GB IBD
- ≈ 20 gigabytes de descarga al mes
- +200 GB de subida al mes
- +6 horas al día ejecutando un nodo completo
- +8 conexiones y pares activos de sincronización
--
La mayoría de las personas ordinarias NO debería ejecutar un nodo completo Necesitamos nodos completos que estén siempre encendidos, y tengan más de 8 conexiones (si usted tiene solo 8, entonces es parte del problema, no de la solución), y tengan una conexión a Internet de gran ancho de banda
Gavin Andresen, Científico Principal de la Fundación Bitcoin, en un artículo de Reddit
- Requerimientos importantes de recursos
- Ancho de banda (principalmente de subida)
- CPU, espacio en disco (debido a las UTXO)
- Incentiva la monopolización
- Participantes poderosos tienen más recursos
- Más influencia
- Basado en la influencia distribuida (red de confianza)
- Nodo se suscribe a una lista de otros nodos
- Densidad de la red determina influencia del nodo
- Previene el desarrollo de poder centralizado
- Si algún nodo incumple,
- ... sus acciones serán visibles (públicas)
- La red puede entonces cortar las conexiones con ese nodo
- Inmune al ataque del 51% (no minado)
- Transacciones significativamente más rápidas
- Ocurren en segundos
- Decisiones tomadas a través del consenso de la comunidad
- Menos ancho de banda que Bitcoin (≈1:25)
- Soporte oficial para dispositivos DIY (RPi, Orange Pi, ...)
- Debe operar de forma autónoma
- Ninguna entidad controla la mayoría de sus tokens
- Datos y registros en una blockchain pública, descentralizada
p.e. las aplicaciones de Bitcoin son de código abierto, ninguna entidad controla Bitcoin y sus registros son abiertos y públicos.
- El propósito de un token es permitir el acceso a la aplicación DApp
- Se deben generar tokens de acuerdo a un algoritmo estándar
- Posiblemente distribuir los tokens al comienzo de operación
- Tokens deben ser necesarios para el uso de la aplicación
- Contribuciones de los usuarios recompensadas con pagos en los tokens de la aplicación
p.e. Bitcoin genera bitcoins (tokens) con un algoritmo predeterminado que no puede ser cambiado. Los tokens son necesarios para que Bitcoin funcione. Los minadores Bitcoin son recompensados con bitcoins por sus contribuciones para asegurar la red Bitcoin.
- Protocolo puede ser adaptado en respuesta a
- propuestas de mejoras
- retroalimentación del mercado
- Cambios decididos por el consenso de la mayoría de sus usuarios
p.e. Todos los cambios a Bitcoin deben ser aprobados por el consenso de la mayoría de sus usuarios a través del mecanismo de la prueba de trabajo.
- Tienen su propia blockchain
Bitcoin, Litecoin y otras alt-coins
- Uso de la blockchain de una aplicación descentralizada tipo I
- Son protocolos
- Tokens que son necesarios para su funcionamiento
OmniLayer (anteriormente Protocolo Master) y Blockstack son ejemplos de aplicaciones descentralizadas de tipo II.
--
- Incrustan datos adicionales en transacciones de DApps tipo I
- Código OP_RETURN de Bitcoin
- Salidas probablemente removibles
- Minadores Bitcoin tendrán la opción de remover esos datos
Blockstack es una DApp tipo II
- Usan el protocolo de una aplicación descentralizada de tipo II
- Son protocolos y tienen tokens que son necesarios para su funcionamiento
Las aplicaciones de Omni (anteriormente Mastercoin), y Blockstack son ejemplos de aplicaciones descentralizadas de tipo III.
- Publicación de las especificaciones
- Distribución de los tokens iniciales
- Delegación de propiedad
- Intenciones y metas de la DApp
- Planes para la distribución de tokens
- Mecanismo para establecimiento de consenso
- Supervisión de la DApp
- Gestión de los beneficios de los desarrolladores
- Descripción técnica de la DApp
- Los tokens son distribuidos a aquellos que contribuyen con más trabajo a la operación de la DApp
Tomando Bitcoin como ejemplo, se distribuyen bitcoins a través de un algoritmo predeterminado a los minadores que verifican transacciones y mantienen la blockchain de Bitcoin.
- Son distribuidos tokens a aquellos que financien el desarrollo inicial de la DApp
Tomando el Protocolo Master como ejemplo, inicialmente fueron distribuidos Mastercoins a aquellos que enviaron bitcoins a una dirección determinada a una tasa de 100 Mastercoins por bitcoin enviado. Los bitcoins recaudados fueron usados entonces para financiar el desarrollo de aplicaciones que promovieran el desarrollo del Protocolo Master.
- Tokens son generados usando un mecanismo predefinido y solo están disponibles para el desarrollo de la DApp
En adición al mecanismo de recaudación de fondos, el Protocolo Master usó el mecanismo de colaboración para financiar su desarrollo futuro. Algunas Mastercoins son distribuidas a través de un sistema de beneficios gestionado por la comunidad basado en el mecanismo PoS.
- Próximo encuentro : Explicación de los proyectos de Skycoin !!!
- Comunidad de Telegram : https://t.me/Skycoin
- Sitio Web : https://www.skycoin.net
- Desarrollo - https://github.com/skycoin
- Canal de Noticias : https://t.me/skycoinnews
- Twitter : https://twitter.com/Skycoinproject
- Soporte : https://t.me/skycoinsupport