Tienda de dapps | Hub de Web3 para eventos y juegos

Literalmente tenemos ese nivel de rendimiento en TOOL. Utiliza consenso no BFT de baja sobrecarga para lograr la transición de estado común para todos los usuarios que intentan ingresar al siguiente bloque. Por lo tanto, solo está limitado por el ancho de banda de la cadena subyacente. Pero si lo implementamos en una cadena con abundante espacio de bloques (estamos abiertos a solicitudes 😁), seguramente igualaría el rendimiento de Mega, al tiempo que sería más flexible que su modelo de secuenciador giratorio tz.

El gran contraataque que cada alt-L1 va a traer a Mega es "también podemos hacer pre-confs, hermano", pero ese no es el nivel. El nivel superior es que podemos ejecutar tx al mismo tiempo que sus pre-confs, PERO TAMBIÉN PODEMOS REFLEJAR ESO INMEDIATAMENTE A OTROS USUARIOS. Podemos hacer eso porque ofrecemos garantías del 99.999% de que una vez que se les entregue ese recibo de tx (tiempo de ejecución de <10ms + distancia al secuenciador) es definitivo. Existe un riesgo de ~0 de que esa transacción se bifurque. Esa confianza significa que otros usuarios pueden actuar INMEDIATAMENTE sobre esa información sin preocuparse de que no sea cierta debido a algo fuera de su control. Componibilidad instantánea del ecosistema. Esto sucederá en un umbral por debajo de lo que es literalmente posible para las cadenas con consenso. Tendrían que redefinir la física. Entonces, a menos que estas cadenas alternativas planeen revivir a Sir Isaac Newton para traer a la base, estarán en desventaja para siempre contra Mega. Aquí hay un ejemplo del mismo equipo que demuestra cómo interactúan las perspectivas de 2 usuarios. Uno compra y el otro obtiene su precio en la curva de inmediato, porque ese nuevo precio es el precio permanentemente nuevo y no "probablemente el nuevo precio para los próximos 3 años". Lo salvaje es @problemchild no cree que este sea el estado final y que haya más jugo para exprimir su aplicación de consumo. Estoy listo para poner esto a la vista para que los optimizadores vean hasta dónde se puede llevar

Lo bueno es que para ser el más eficiente, TOOL no requiere colocación con validadores L1, sino más bien una colocación de participantes de TOOL, para que puedan reasignar dinámicamente su infraestructura entre regiones para ubicarse donde ocurre la mayor actividad, mientras que tampoco es un requisito estricto, por lo que el sistema será más redundante y abierto a diferentes patrones de uso que evolucionarían naturalmente.

tbf, creo que el mejor de los casos es mucho más fácil de lograr con su modelo, pero también es una compensación, ya que fuerza patrones de uso específicos. Así que no afirmaré que TOOL es más eficiente o "mucho mejor" que Mega, ya que operamos en diferentes planos del espacio de compensación. Pero ciertamente no es "peor" en general, jaja.

Entonces, en general, me siento comprensivo y curioso por ver cómo se desarrollará el ciclo de adopción de Mega, y no creo que sea un competidor muy directo de TOOL atm, ya que Mega es un L2 con la máxima obstinación, y TOOL es un marco neutral para L1, cuyo objetivo es ser lo suficientemente flexible como para representar las necesidades de la base de usuarios subyacente. en su mayoría no los obliga a actuar de una manera particular o rediseñar aplicaciones desde cero.