A modo de remember....
que tiempos aquellos.. cuando salió la imagen
Del lanzamiento de la red de pruebas!!!!!!!
Esto trabajando sobre un artículo que hace referencia a una comparativa entre EOS y aelf..
En el mimo se pone de manifiesto la forma en que EOS la fastidió en el lanzamiento de su red, mientras aelf lo hizo increiblemente bien
y eso que la recaudación de EOS ascendía a los $800Millones (ICO)  mientras que aelf apenas llegó a los $15Millones (ronda privada)

How many times have you heard about cross chains interactions? dont worry.. we will teach you what is all this about

Has escuchado alguna vez hablar de las operaciones entre distintos blockchains?? aqui tienes!

Here you got the song chosen as "song of the week" by aelf.. enjoy

https://youtu.be/iEINM8Xnnzk

Aqui te dejo con la canción de la semana de aelf!

https://youtu.be/iEINM8Xnnzk

Episode 5 of The Dapper Weekly felt like I was looking at twitch... decentralized! @OfficialDLive Who else can you bring to the world of Blockchain?

https://t.co/x623P8wuZL

Sabías que el Youtuber número uno del mundo, se ha mudado al blockchain? es época de cambios

https://t.co/x623P8wuZL

Larimer uses the example of a radio station to illustrate the resilience of DPoS to attacks. On this radio station, anyone can broadcast (mine a block), and everyone must decide if they want to listen to these broadcasts (verify the block.)

With PoW, those who broadcast the loudest, or use the greatest hash power, have control of the network. This is especially true with mining pools which can become large enough to gain a 51% share of overall hash rate. Furthering this analogy, PoS awards those with the most money to stake with the greatest proportion of airtime.

Alternatively, DPoS gives each stakeholder a vote in who runs the radio transmitter. Unlike a pure PoS model, DPoS allows voters to elect the transmitters (nodes), giving everyone the opportunity for equal airtime. Under this system, nodes which act against the interests of the network can be voted out by the token holders, who have a vested interest in the future of the network.

Looking back at aelf again, they have taken this a step further with a performance upgrade which doubles as an extra security measure. Every node in the ecosystem is a cluster node, made up of many anonymous and remote workers all around the world. This makes it even more difficult to attempt an attack based upon accessing the equipment on the system.

While there is not yet any perfect consensus mechanism, DPoS provides a robust deterrent to bad actors. In a similar way to representative democracies in government, a node can only become a node, and remain a node, with the approval of a voting majority. Like the Byzantine generals, if a node is perceived as traitorous, then the token holders will exercise the power of their votes and remove it

Ilustrando la Resistencia al ataque del 51%




Larimer utiliza el ejemplo de una estación de radio para ilustrar la resistencia de DPoS a los ataques. En esta estación de radio, cualquiera puede transmitir (minar un bloque), y todos deben decidir si quieren escuchar estas transmisiones (verificar el bloque).

Con PoW, aquellos que transmiten más fuerte, o usan el mayor poder de hash, tienen el control de la red. Esto es especialmente cierto en el caso de los fondos de minería, que pueden llegar a ser lo suficientemente grandes como para ganar un 51% de la tasa de hash total. Siguiendo con esta analogía, el consenso PoS premia a aquellos que tienen más dinero para dejar en Stake con la mayor proporción en tiempo de emisión

Alternativamente,  el DPoS da a cada parte interesada un voto sobre quién dirige al radiotransmisor. A diferencia de un modelo de PoW puro, el DPoS permite a los votantes elegir los transmisores (nodos), dando a todos la oportunidad de disponer de igual tiempo de emisión. Bajo este sistema, los nodos que actúan en contra de los intereses de la red pueden ser eliminados por los titulares de tokens, que tienen un interés personal en el futuro de la red.

Mirando hacia atrás, han dado un paso más allá con una mejora de rendimiento que también es una medida de seguridad adicional. Cada nodo del ecosistema es un nodo de clúster, formado por muchos trabajadores anónimos y remotos de todo el mundo. Esto hace aún más difícil intentar un ataque basado en el acceso a los equipos del sistema.

Aunque todavía no existe un mecanismo de consenso perfecto, el DPoS proporciona un fuerte elemento disuasorio para los malos actores. De manera similar a las democracias representativas en el gobierno, un nodo sólo puede convertirse en un nodo, y seguir siendo un nodo, con la aprobación de una mayoría de votos. Como los generales bizantinos, si un nodo es percibido como traidor, entonces los titulares de tokens ejercerán el poder con sus votos y lo eliminarán.

Cómo se logra escalabilidad y resiliencia aplicando  DPoS



Mediante DPoS, los nodos son elegidos por los titulares de tokens. En el caso de aelf, el número de nodos se determina por la fórmula 2N+1, donde N comienza en 8 y aumenta en 1 cada año. Así, el primer año hay 17 nodos, el segundo año 19 nodos y así sucesivamente. Esta fórmula limita el número de nodos delegados, a diferencia de la PoW en el que cualquier nodo no fiable puede unirse por iniciativa propia.

Al aumentar gradualmente el número de nodos cada año, esta fórmula también permite aumentar el volumen de transacciones que pasan a través de la red aelf. Por lo tanto, el DPoS proporciona un mecanismo de consenso más escalable que el PoW.

Sin embargo, algunos críticos creen que la limitación del número de nodos bajo DPoS aumenta la centralización y pone en riesgo la regla de la plutocracia. Dan Larimer, el inventor del DPoS, no está de acuerdo, señalando que estos críticos pasan por alto un punto crucial: la delegación descentraliza el control de la red a todos los poseedores de tokens, lo que, a su vez, proporciona un medio más eficaz para evitar la centralización.

How DPoS Achieves Both Scalability and Resilience




In DPoS, nodes are elected by token holders. In the case of aelf, the number of nodes is determined by the formula 2N+1, where N starts at 8 and increases by 1 each year. So, the first year there are 17 nodes, the second year 19 nodes and so on. This formula limits the number of delegated nodes, unlike in PoW where any untrusted node may join at will.

By incrementally increasing the number of nodes each year, this formula also allows for increases in the volume of transactions passing through the aelf network. Thus, DPoS provides a more scalable consensus mechanism than PoW.

However, some critics believe that , limiting the number of nodes under DPoS increases centralization and risks the rule of plutocracy. Dan Larimer, the inventor of the DPoS, disagrees, pointing out that these critics miss a crucial point — delegation decentralizes the control of the network to all of the token holders, which, in turn, provides a more effective means of preventing centralization.

Regarding our consensus mechanism.. have you ever heard about the Byzantyne generals problem?



Because blockchain networks depend on consensus between many nodes in the network, they have no single “point of attack,” in contrast to centralized systems which rely on servers. As a result, they’re generally considered more resilient to traditional hacking, but even in a decentralized computing environment, bad actors can still band together to bring down the system, a dilemma that programmers have been confronting for the past four decades.

First described in a 1982 paper, the “Byzantine Generals Problem” describes a city under siege from multiple divisions of the Byzantine army, each led by a different general. To launch a successful raid, the generals must coordinate their attacks simultaneously, but each division is camped in a different location surrounding the city, and the generals can only communicate with one another via messengers.

The problem is that some of the generals may have different ideas about when to attack or retreat, and no one general can be sure that the others are all loyal. There may be one or more traitors. Each general also needs his lieutenants to implement instructions.

Therefore, the army needs an algorithm that fulfills two conditions:

1. All loyal generals agree to implement the same plan, and;

2. Any traitors cannot “trick” loyal members into adopting a bad plan.

alguno ha escuchado alguna vez hablar del problema de los generales bizantinos?



Dado que las redes de cadenas de bloques dependen del consenso entre muchos nodos de la red, no tienen un "punto de ataque" único, a diferencia de los sistemas centralizados que dependen de los servidores. Como resultado, generalmente se les considera más resistentes ante los tradicionales ataques de hackers, pero incluso en un entorno informático descentralizado, los malos actores pueden unirse para derribar el sistema, un dilema al que se han enfrentado los programadores durante las últimas cuatro décadas.

Descrito por primera vez en un documento de 1982, el "Problema de los Generales Bizantinos" describe una ciudad sitiada por múltiples divisiones del ejército bizantino, cada una de ellas dirigida por un general diferente. Para lanzar una incursión con éxito, los generales deben coordinar sus ataques simultáneamente, pero cada división acampa en un lugar diferente alrededor de la ciudad, y los generales sólo pueden comunicarse entre sí a través de mensajeros.

El problema es que algunos de los generales pueden tener ideas diferentes sobre cuándo atacar o retirarse, y ningún general puede estar seguro de que todos los demás son leales. Puede haber uno o más traidores. Cada general también necesita que sus tenientes implementen las instrucciones.

Por lo tanto, el ejército necesita un algoritmo que cumpla dos condiciones:

1. Todos los generales leales están de acuerdo en implementar el mismo plan, y;

2. Los traidores no pueden "engañar" a los miembros leales para que adopten un mal plan.


He encontrado un ejemplo práctico para aquellos que tengan tiempo y ganas...  aqui está todo muy desarrollado, pero es bastante más complejo https://medium.com/@marvin.soto/el-problema-de-los-generales-bizantinos-pgb-e0cb8c4279c2

In a previous post, we outlined why the flaws with proof of work (PoW) and proof of stake (PoS) led aelf to choose a different consensus model. The DPoS model aligns closely with our philosophy that the token holders should have the greatest right in the future of the system, and that token holders’ interests are linked with the destiny of aelf.

In this post, we will look at a further benefit of using the DPoS consensus model — namely, how DPoS coordinates trusted nodes in order to defend against the risk of a “51% attack.”

But what are these attacks, and how do they come about in the first place?

En un artículo anterior, esbozamos las debilidades de los mecanismos de prueba de trabajo (PoW) y de prueba de participación (PoS), que nos llevaron a elegir un modelo de consenso diferente. El modelo DPoS se alinea estrechamente con nuestra filosofía de que los poseedores de tokens deben tener el mayor derechosobre el futuro del sistema, y que los intereses de los mismos, están vinculados con el destino de aelf.

En el siguiente artículo, veremos otro beneficio de utilizar el modelo de consenso DPoS, en particular, la manera en que coordina DPoS los nodos de confianza para defenderse del riesgo de un "ataque del 51%".

Pero, ¿qué son estos ataques y cómo se producen en principio?

In order to maintain the transparency of the ELF token distribution, we want to share the detailed ELF token distribution based on the Distribution Ratio and allocation as shown on the aelf official website:



Foundation (12% locked, for aelf ecosystem, support aelf marketing, and sustain the development of aelf project):
0xae3F5961937CB0171F127075A99550978b31ACA1

Foundation (13% unlocked, but still in the following address):
0x384Cc0b3a514216627F7054B30ea4e7d5F54EEa9

Marketing/Bounty Program (6% locked, for market expansion and promote the activeness of the community):
0xEA1bb5B01bFE95e0cff237C9b9126526CB12a768

Market/Bounty Program (1% unlocked, but still in the following address):
0xd3199DB5B7d94596546276c4A63D3dF6b84854f7

Advisors/Partnership (2.5% locked):
0xC7a6c4d547C1b1098Eb3C01F1dd3f25E1d4c4FE4

Advisor/Partnership (4.5% unlocked, but still in the following address):
0xA4aE4e009E9Ec51A4B01Dfb700674E3CC0e8E49B

Team (4% locked):
0xffe79ac093e5aafD35B5e118c58dbcEe06250749

Team (12% unlocked, but still in the following address):
0xfE1539ac28816D9792D56Bc9AD745dAAD4CFDd47

Anuncio acerca de la distribución de tokens



Con el fin de mantener la transparencia de la distribución de los tokens ELF, queremos compartir la distribución detallada de los tokens ELF basada en el ratio de distribución y la asignación según se indica en la página web oficial de aelf:

Fundadores (12% bloqueado, para el ecosistema de aelf, apoyar el marketing de aelf, y sostener el desarrollo del proyecto):
0xae3F5961937CB0171F127075A99550978b31ACA1

Fundadores (13% desbloqueado, pero aún en la siguiente dirección):
0x384Cc0b3a514216627F7054B30ea4e7d5F54EEa9

Programa de marketing y bounty (6% bloqueado, para la expansión del mercado y promover la involucración de la comunidad):
0xEA1bb5B01bFE95e0cff237C9b9126526CB12a768

Programa de marketing y bounty (1% desbloqueado, pero aún en la siguiente dirección):
0xd3199DB5B7d94596596546276c4A63D3dF6b84854f7

Asesores/Alianzas estratégicas (2,5% bloqueado):
0xC7a6c4d547C1b1098Eb3C01F1dd3f25E1d4c4FE4

Asesores/Alianzas estratégicas  (4,5% desbloqueado, pero aún en la siguiente dirección):
0xA4aE4e009E9E9Ec51A4B01Dfb700674E3CC0e8E49B

Equipo (4% bloqueado):
0xffe79ac093e5aafD35B5e118c58dbcEe06250749

Equipo (12% desbloqueado, pero aún en la siguiente dirección):
0xfE1539ac28816D9792D56Bc9AD745dAAD4CFDd47

Un buen producto debe ser estable y completo. EL lanzamiento de cualquier producto no competitivo no tiene sentido alguno para mi.
POr si os preguntais a que se debe el retraso...
la respuesta es contundente
si no podemos entregar alo perfecto, seguimos trabajando para conseguirlo!

A preview of the success and adoption of aelf worldwide..

aqui teneis las utlimas actualizaciones de desarrollo