Réflexions brutes concernant la prochaine grande mise à niveau (s)
Lien de publication d’origine
Vous ne terminez pas sur un crescendo, Et ce n’est un secret pour personne que plusieurs mises à niveau prévues attendent sur la ligne de touche KASPA. Principalement, le protocole Dagknight (DK) et le pont ZK L1L2. Ces deux efforts majeurs peuvent sembler indépendants, mais je vois un fort mérite de les regrouper en une seule fourche (raisons ci-dessous). Je soutiens également que cet effort groupé est la bonne fenêtre pour incorporer les changements de L1 fondamentaux nécessaires pour soutenir les recherches en cours sur la résistance au MEV et le vote des oracle.
Un mot sur le report de DK à ce point. Je reconnais que par énoncés antérieurs, nous nous attendions à être post-DK maintenant. Contexte pour le long retard: (1) Après la réécriture de la rouille, se déplaçant de 1 → 10 bps (blocs / sec) était trop naturel à un suivi pour ignorer, et j’ai plongé en ~ 1 ans de travail là-bas. (2) une solide communauté de la communauté pour les contrats intelligents; En l’absence de comités officiels, planifiant la prochaine phase, nous avons estimé que la priorisation de l’activation des contrats intelligents permettrait à une forme de communauté de constructeurs autour de la couche de l’application Kaspa, et que déchaîner ce potentiel (et ses effets de riding) nous permettra de recentrer sur la perfection L1 sans la croissance de l’écosystème de l’écosystème.
Cet article fournit un aperçu des oiseaux des oiseaux des efforts actifs + KASPA R&D à venir et esquisse leur graphique de relation.
DK: Dagknight est un document de recherche en ordonnance de 22 par moi-même et @hashdag; Il évolue Ghostdag (GD). Un article de suivi (principalement écrit) sera en profondeur DK à travers: – Avantages / applications pratiques de sa propriété abstraite «non a priori de délai» – Une rupture en quatre composants principaux → phases de développement brutes – Implications plus larges système / consensus – Recherche appliquée pour des algorithmes incrémentaux efficaces (Notablement la cascade de vote) – Protocol (et documents) Limites pratiques + mises en garde d’ingénierie
ZK: Au cours de la dernière année, il y a eu un effort visible en cours pour établir le paysage de ZK sur Kaspa. Les résultats de ces efforts peuvent être principalement considérés dans le forum de recherche de KASPA dans la catégorie L1L2. L’approche de KASPA consiste à prendre en charge ZK Rollups, où «basé» signifie que les couches ZK / Rollups / DAPP s’engagent pleinement dans le séquençage L1 – donc L1 sert les trois rôles: séquençage, disponibilité des données, règlement. Les mécanismes de base pour soutenir cela sont largement établis. Le domaine principal encore sous des recherches lourdes est la composabilité atomique / synchrone (transactions multi-virages qui se terminent atomiquement). Expliquant la vision et la cartographie des recherches actuelles, il mérite son propre poste dédié.
Pourquoi regroupez DK + ZK: Leurs complexités techniques se chevauchent à peine, de sorte que le développement peut se dérouler en parallèle et fusionner proprement. C’est le cas d’ingénierie. Il y a aussi un cas de sécurité: nous (fortement) conjecture DK donne une convergence pratique plus rapide de l’ordre total de DAG. En fonctionnement normal, le delta est probablement sans conséquence; Sous de puissantes tentatives d’attaque, la convergence de DK pourrait être beaucoup plus rapide – possible par des ordres de grandeur. La convergence plus rapide de l’ordre total est particulièrement précieuse pour les systèmes à contrat intelligente qui sont fortement sensibles à l’ordre. Cela renforce encore le cas pour lier les deux mises à niveau.
Éléments supplémentaires qui devrait être expédié avec eux est le soutien aux enchères inversées des enchères et aux mécanismes de vote Oracle (deux de @hashdagLes efforts de recherche en cours avec @YAISH_AVIV et @elimmeme respectivement; Voir ses récents pourparlers de Sydney / HK), saisissant l’occasion de résoudre certains des problèmes les plus difficiles de Defi en utilisant la structure unique de Kaspa. Une fois que les contrats intelligents complets sont en direct, nous hériterons inévitablement des points faibles de Mev + Oracle vu ailleurs. En apportant maintenant quelques changements de consensus minimaux à haut niveau, nous pouvons «appliquer le remède avant le coup». Le coût d’ingénierie ici est négligeable par rapport à DK + ZK tandis que l’écosystème à l’envers est important. Voici comment nous pouvons approcher chacun:
Mev. Approche proposée: Inversez les enchères dans lesquelles les mineurs offrent des pots-de-vin aux utilisateurs pour les droits d’ordre des transactions (ou de bundle). Le Dag parallèle de 10 bps de Kaspa produit déjà une compétition intra-ronde; La formalisation d’un chemin de pots-de-vin capture cette valeur pour les utilisateurs au lieu des courtiers privés. Les exigences en L1 sont petites: ajoutez une voie de pickback canonique et une règle d’ordre des enchères déterministe dans le consensus (comment classer les offres contradictoires; les détails sont toujours ouverts afaik). Les raffinements théoriques du jeu peuvent suivre après le Fond, mais un chemin de base devrait exister à mon avis.
Oracles. La stratégie d’Oracles est de tirer parti du BPS élevé de KASPA pour permettre un réseau d’attestation robuste en temps réel, avec des données agrégées à partir de nombreux mineurs chaque tour. Du point de vue de la L1, la principale considération est de savoir s’il faut lier ce système à POW pour une plus grande résistance à la sécurité / à Sybil. L’étape pratique serait d’ajouter des mécanismes de vote de mineurs au niveau du consensus. Il s’agit d’un changement préparatoire à faible coût qui offre une flexibilité future importante pour les conceptions Oracle L2.
Dans l’ensemble, je m’attends à ce que les succursales DK / ZK commencent bientôt à atterrir dans le principal référentiel de RK. Dans l’attente de cette transformation en un beau voyage de codage open source décentralisé