Kreditz Design Blog

Todas las partes del desarrollo de una criptomoneda son importantes, pero la sincronizacion correcta de la red es crucial, amen que requiere procedimientos para manejar los imprevistos (que seguro los abrá) sin alterar la cadena de bloques de manera catastrófica. Hace falta que el protocolo incluya medidas de seguridad para cualquier cosa que pueda ocurrir, e incluso, para cosas que ni nos podamos imaginar ahora. Antes de empezar, hay que conocer algunos conceptos importantes para comprender como se sincroniza una red P2P en base a un consenso de la mayoria de los usuarios conectados. Informacion flotante. Toda la informacion que circula en la red que no esta relacionada con movimiento de monedas a ser guardada en la cadena de bloques se puede denominar informacion flotante. Un claro ejemplo de ello es la informacion de los nodos disponibles: todos los usuarios comparten la informacion de los nodos a los que ellos han podido acceder, pero eso nunca se guardara en la cadena de bloques. ...

El sumario de cuentas es un archivo que contiene, entre otras cosas, el saldo de todas las direcciones que en algun momento han recibido monedas de cualquier procedencia, sea por minado o por transferencia desde otra direccion. Las direcciones se van añadiendo por orden, la mas antigua de primera y la mas reciente de ultima. (Esto implica que la primera direccion sera la del minero del bloque 1) Esto significa que todos los usuario deben tener un sumario de cuentas completamente igual, que arrojara un hash identico: esta es una de las medidas de seguridad para garantizar la integridad de la red. En el sumario de cuentas, aparte de la direccion y el saldo, tambien se almacena el alias de esa direccion (si lo hubiese), el numero del bloque en el cual participo en una orden por ultima vez (sea como remitente, receptor, personalizacion o comision) y un valor de puntuacion (mas adelante veremos lo que significa). Su importancia es tal que es lo primero que se sincroniza al conectarse a la r...

En los bloques, aparte de la informacion relativa al bloque, se almacenan todas las operaciones que involucren un movimiento de monedas y hayan sido realizadas desde la emision del ultimo bloque.  Transferencia entre direcciones. Lo mas comun es el envio directo de monedas desde una direccion a otra. Esto se llama transferencia, y debe incluir la siguiente informacion: El timestamp en que se realiza la operacion. La clave publica de quien realiza el envio. Ya que la direccion se obtiene a partir de la clave publica, enviar esta en lugar de la direccion hace mas eficiente el proceso de verificacion de la operacion. La direccion que recibira las monedas. El monto de monedas disponible en la direccion que envia antes de realizar la transferencia. Esto evita las posibilidades de doble gasto. El monto que desea transferir. El concepto, si el remitente desea incluir alguno. La firma con la clave privada que autentifica la operacion. Finalmente, el identificador (ID) de la transferencia. ...

Toda cadena de bloques empieza por el bloque 0, que tiene unos datos predefinidos: Nadie ha podido hacer transacciones ya que no se han generado monedas aun. No hay un resultado del problema criptografico, ya que no existe un bloque anterior. Como no hay solucion de problema, no hay monedas acreditadas a ninguna cuenta (algunos diseñadores usan este bloque para asignar cierta cantidad de monedas a una cuenta ya existente de su propiedad: a esto se le denomina preminado) En cualquier caso, el bloque 0 debe tener la misma estructura que tendran todos los siguientes bloques, es por eso que primero debemos desarrollar el procedimiento que crea bloques nuevos y despues usarlo para el crear el primer bloque. Hagamos una pausa para explicar lo que es una funcion hash, ya que a partir de ahora seran de suma importancia. Una funcion hash es aplicar una serie de procedimientos matematicos a algo (puede ser una cadena de texto, un archivo, casi cualquier tipo de informacion) que da como resultado...

Siguiendo con lo que vimos en la entrada anterior, creamos una nueva unidad para las funciones relacionadas con el tiempo, y un interruptor al inicio que verifique la validez de nuestro tiempo local. Tambien necesitaremos un archivo que almacene la informacion de los servidores NTP para poder intercambiarlos y compartirlos en la red. La funcion que usaremos para incluir la hora de red sera ' UTCTime '. Para organizar mejor el programa, haremos que todos los archivos necesarios sean colocados en una carpeta aparte: ' MPDATA '. Desde luego, ya que OpenSSL es FUNDAMENTAL para el funcionamiento del programa, tambien hacemos la verificacion al iniciar. Asimismo incorporamos el procedimiento para la creacion/carga de carteras que ya habiamos implementados para PaskalWallet, ya que siempre debe haber una cartera asociada al momento de ejecutar el programa. Ver las direcciones de la cartera activa es una informacion muy importante, por tanto incluiremos un espacio para mostrarl...

La hora en internet es en ocasiones algo complicado para algunas personas, ya que estan interconectadas personas de practicamente todos los usos horarios que existen. Una manera de normalizar y facilitar la comunicacion es el empleo del  Tiempo Universal Coordinado  o UTC.  Crearemos una sencilla aplicacion para visualizar claramente como obtener el UTC desde una amplia red de servidores fiables que usan el  Network Time Protocol  o NTP, el cual esta vigente desde 1981 y es uno de los mas antiguos protocolos aun activos en Internet: cuando algo funciona perfectamente no es necesario cambiarlo. La unidad Indy para lazarus incluye un cliente para conectarse a dicha red: TIdSNTP. Lo que haremos es buscar algunos servidores de NTP y contrastarlo con la hora del computador del usuario para verificar si es correcta. Los servidores NTP dan una respuesta en formato DateTime, por lo que es necesario aplicar una funciones para convertirlo en formato TimeUnix. Time ut...

Como vimos en la entrada anterior, lo primero es crear una red P2P para todos los usuarios . Para esto, en Paskal usaremos una unidad desarrollada por terceros: Indy, la cual ya añadimos a nuestra IDE de lazarus al inicio. Ahora solo debemos añadirlo al proyecto en Inspector de Proyecto -> Añadir nuevo Requerimiento. Como todo usuario debe ser cliente y servidor al mismo tiempo, es necesario que incluyamos un servidor y tantas conexiones de cliente como deseemos. Con cuantos usuarios simultaneos puede estar conectado cada uno? En teoria, el numero es infinito, pero a mayor numero de conexion (entrantes o salientes) mas lento ira el programa. Por otra parte, un numero demasiado bajo restara seguridad a la red. Tomando en consideracion la robustez de otras redes P2P, el numero idoneo esta entre 5 y 15. Este numero esta definido por la constante ' Maxconecciones '. Empezamos entonces añadiendo 1 servidor (que puede recibir 15 conexiones entrantes) y canales suficientes para 15 ...