Validation de la disponibilité des données natives de Bitcoin dans un environnement L2 à ultra faible latence @megaeth , @risechain , @nubit_org Dans la blockchain, l'expression ultra faible latence ou temps réel ne signifie pas seulement que la vitesse ressentie est rapide, mais désigne une structure où l'exécution, la réponse et la réflexion de l'état sont fournies de manière cohérente à un niveau plus rapide que les limites de perception humaine. Les systèmes de couche 2 haute performance récemment apparus sont conçus sur la base de délais d'exécution à l'échelle des millisecondes et d'un très haut débit, et dans ce processus, la séparation des couches d'exécution et de validation est devenue courante. Dans un tel environnement, la disponibilité des données ne détermine pas directement la vitesse, mais joue plutôt un rôle fondamental permettant à quiconque de valider les transitions d'état plus tard. Les systèmes L2 en temps réel utilisent des techniques pour exécuter les transactions avant de les inclure complètement dans un bloc ou pour diviser le bloc en unités très petites afin de confirmer l'ordre. Cela permet aux utilisateurs de vérifier presque immédiatement les résultats, mais la validation cryptographiquement complète se fait beaucoup plus tard. Dans cette structure, la couche de disponibilité des données doit garantir qu'un nombre suffisant de données est rendu public dans un délai raisonnable pour permettre la validation, et en cas de retard ou de dissimulation, les participants au système doivent faire confiance à l'honnêteté du séquenceur pendant cette période. La disponibilité des données natives de Bitcoin est une approche qui vise à fournir cette fonction de validation en s'appuyant directement sur la blockchain de Bitcoin. Les blocs de Bitcoin sont générés en moyenne toutes les 10 minutes, et la capacité de données pouvant être contenue dans un bloc est limitée. Cette structure offre une forte sécurité économique et une forte résistance à la censure, mais présente une limite claire en termes de fréquence de publication des données et de débit. En conséquence, la disponibilité des données basée sur Bitcoin repose sur un débit d'environ quelques kilooctets par seconde et un délai de confirmation d'au moins quelques minutes. Dans un environnement L2 en temps réel, alors que le délai d'exécution est de quelques millisecondes, la confirmation de la disponibilité des données peut prendre plusieurs minutes, ce qui crée un écart extrême entre l'exécution et la validation. Pendant cet écart, les utilisateurs ne peuvent pas valider l'état de manière indépendante ni récupérer leurs actifs en toute sécurité, et ils ne peuvent pas non plus vérifier immédiatement si les données ont réellement été publiées. Cela signifie que l'effet de minimisation de la confiance basé sur la validation, que la couche de disponibilité des données était censée offrir, est considérablement retardé. Les systèmes qui mettent en œuvre la disponibilité des données natives de Bitcoin utilisent des mécanismes auxiliaires tels que le consensus par comité, l'échantillonnage de données et l'ancrage périodique dans Bitcoin pour atténuer ces limites. Cependant, ces méthodes ne peuvent pas fournir le court délai de validation requis par un environnement d'exécution en temps réel, à moins de changer la vitesse de traitement de Bitcoin lui-même et le cycle de génération des blocs. Le fait qu'il faille au moins un bloc de temps pour juger et répondre de manière définitive à la dissimulation ou au retard des données reste inchangé. Cette caractéristique devient encore plus évidente dans des applications extrêmement sensibles aux délais, comme le trading à haute fréquence ou les jeux en temps réel. Dans un environnement où un très grand nombre de transactions se produisent en peu de temps, l'espace de bloc Bitcoin ne peut pas accueillir la demande de disponibilité des données, et le retard de validation perturbe également le fonctionnement normal de l'application. En revanche, dans des applications où la fréquence des transactions est relativement faible et où la sécurité du règlement final est plus importante, la disponibilité des données basée sur Bitcoin peut jouer un rôle constant. En résumé, dans un environnement L2 à ultra faible latence, la disponibilité des données natives de Bitcoin présente des limites structurelles en termes de retard de validation et de contraintes de débit. Bitcoin offre une sécurité et une fiabilité puissantes, mais en raison de ses caractéristiques de conception, il n'est pas adapté à être utilisé comme une couche de disponibilité des données basée sur l'exécution en temps réel. Dans les systèmes L2 en temps réel, la disponibilité des données natives de Bitcoin reste un point de référence auxiliaire, lent mais hautement sécurisé, plutôt qu'un principal moyen de validation soutenant l'exécution, comme le confirment les analyses objectives jusqu'à présent.