j'ai passé un excellent moment à animer la 2ème session du @WPReadingClub à SF avec @BrianSeong hier soir @ethereumhouseSF, réunissant des chercheurs en confidentialité, des développeurs, des étudiants pour discuter du cadre de confidentialité Kohaku d'Ethereum. j'ai beaucoup appris des experts, quelques notes brèves : > kohaku est un sdk/couche d'abstraction pour la confidentialité, qui appelle des protocoles sous-jacents comme @RAILGUN_Project @0xMiden @hinkal_protocol en arrière-plan. > mon modèle mental pour kohaku est comme un sdk de connecteur viem/wagmi pour les portefeuilles. je me souviens (sans nostalgie) d'avoir écrit des injecteurs de portefeuilles manuels dans le début de 2022. des choses comme viem/wagmi fournissent maintenant une interface standard pour obtenir les états de connexion des portefeuilles/gérer les chaînes pour rendre tout 1000x plus facile. la confidentialité aujourd'hui est comme la scène des portefeuilles début 2022, nécessitant des intégrations manuelles pour tout, et kohaku essaie d'abstraire tout cela en fournissant des points de terminaison communs comme `sendPrivate`, `shield`, `unshield` > cependant, par rapport aux abstractions de portefeuilles, il y a une disparité beaucoup plus grande sur les solutions de confidentialité (via des pools protégés, ZK, FHE, TEEs, MPC) utilisées en arrière-plan. par exemple, Railgun est une solution au niveau du protocole, tandis que quelque chose comme Miden est un L2, avec différentes propriétés/garanties de confidentialité. Les développeurs doivent avoir une très bonne compréhension de ce que le cadre sous-jacent qu'ils utilisent peut et ne peut pas faire, beaucoup plus que dans le cas des portefeuilles. > la conformité est toujours une grande épine dans le pied de tout le monde pour la confidentialité (post Tornado). à mon avis, la confidentialité n'est jamais un concept monolithique, c'est toujours "la confidentialité de [quelque chose] par rapport à [quelqu'un]". avoir la confidentialité des transferts de tokens par rapport aux observateurs on-chain + aux échanges de garde est DÉJÀ une amélioration fonctionnelle énorme par rapport à ce que nous avons aujourd'hui, surtout pour des contextes b2b comme la paie privée/la chaîne d'approvisionnement d'entreprise, où mettre des choses on-chain est un secret d'entreprise. je pense que les clés de visualisation réglementaires/certaines preuves d'exclusion ZK pourraient être suffisantes à ce stade pour débloquer les cas d'utilisation à forte valeur ajoutée. comme toujours, j'ai adoré animer ces sessions approfondies de nerds + j'en organiserai d'autres à l'avenir. si vous êtes à SF/la baie, assurez-vous de nous rejoindre la prochaine fois !