0xMinh

Auparavant, je partais du principe que la sécurité des transactions dépendait principalement de la solidité de la plateforme. Si le système est stable et qu’il dispose de mécanismes de protection, le reste relève presque entièrement de la responsabilité de l’opérateur.

En relisant attentivement la documentation de Binance P2P, un détail m’a fait m’arrêter. La plupart des mécanismes de protection n’ont pas été conçus pour prendre la décision à la place des utilisateurs ; ils visent plutôt à réduire le risque lorsque chaque partie doit malgré tout assumer elle-même la responsabilité de ses actions.

Au départ, je pensais que l’escrow était l’élément décisif du niveau de sécurité. Puis j’ai compris que l’escrow ne fait que conserver les fonds pendant la transaction : il ne peut ni vérifier le contenu d’une conversation en dehors de la plateforme, ni empêcher l’utilisateur d’envoyer de l’argent vers le mauvais compte, ni confirmer tant que le paiement n’a pas réellement été reçu. J’ai dû relire la partie sur le processus de traitement des litiges pour bien voir cette limite.

D’après mon point de vue actuel, Binance P2P ne cherche pas à supprimer le besoin de confiance : au contraire, le système tente de réduire la dépendance à la confiance entre deux personnes en ajoutant un mécanisme d’escrow, des procédures de vérification et un processus de résolution des litiges. Les utilisateurs doivent toujours faire confiance à Binance, en tant qu’intermédiaire chargé de conserver les actifs pendant la transaction et d’exécuter le résultat en cas de litige. La vraie différence réside dans la manière dont la responsabilité est plus clairement répartie entre la plateforme et l’utilisateur.
Ce qui continue de me faire réfléchir n’est donc pas le mécanisme d’escrow, mais un système qui n’est réellement sûr que lorsque l’utilisateur comprend précisément ses limites.
#binancep2pantoan @Binance Vietnam

Il fut un temps où je me disais par défaut que la présence d’un fonds important dans le cap table était un signal très fort. Il me suffisait de voir ce nom pour avoir tendance à croire que la partie la plus difficile du processus d’évaluation était déjà faite.

Mais en relisant attentivement l’investissement d’a16z dans Babylon, je me suis mis à envisager les choses sous un autre angle. L’engagement de 15 millions de dollars, annoncé assez tôt, alors que Trustless Bitcoin Vaults n’en est qu’à la phase testnet et que de nombreux détails d’implémentation restent encore à finaliser. Cela m’a fait comprendre que ce n’était pas encore une validation d’un système déjà abouti.

Au départ, j’ai considéré cet investissement comme une preuve, puis je me suis rendu compte que je faisais une confusion entre deux notions différentes. Vu aujourd’hui, cela ressemble davantage à un pari sur la thèse de conception et sur la capacité d’exécution de l’équipe qu’à une affirmation selon laquelle toutes les hypothèses cryptographiques et de sécurité de la conception reposant sur BitVM3 et l’architecture des vault ont déjà été vérifiées dans des conditions réelles.

Cela m’a conduit à réfléchir davantage à la manière dont nous lisons les signaux du marché. Une organisation d’investissement peut consacrer énormément de ressources à la due diligence, mais ce processus ne peut pas remplacer ce que seul le réseau et les utilisateurs peuvent réellement vérifier. La confiance de l’investisseur et les preuves techniques semblent toujours appartenir à deux niveaux d’évaluation différents.
La question la plus intéressante est donc la suivante : dans une infrastructure encore très en développement comme Babylon, quelle part de notre attention faut-il accorder à la confiance que portent les fonds, et quelle part à ce que seul le temps, ainsi que l’usage réel, pourra confirmer.
#baby $BABY @BabylonLabs_io

Tôi từng nghĩ một trải nghiệm tốt chỉ cần đủ nhanh và đủ trực quan. Nếu một giao diện bắt người dùng chờ quá lâu tôi gần như mặc định đó là điểm cần được tối ưu.

Khi tự mình thử peg-in bằng signet BTC trên Babylon, cảm giác đầu tiên cũng không khác. Xác nhận giao dịch, đợi, mười hai block. Gần hai giờ, màn hình chỉ hiển thị số block tăng dần và thông báo vault sẽ khả dụng sau khi giao dịch đạt đủ xác nhận. Mọi thứ đều hoạt động đúng chỉ là tôi không cảm thấy điều gì đang thực sự diễn ra phía sau.

Ban đầu tôi nhìn mười hai lần xác nhận như một khoảng thời gian chờ. Sau đó tôi mới nhận ra mình đang tách trải nghiệm khỏi thiết kế hệ thống. Tôi phải đọc lại phần mô tả về Bitcoin finality mới hiểu mỗi block không chỉ là thời gian trôi qua, mỗi xác nhận mới khiến xác suất đảo ngược giao dịch giảm rất nhanh và chi phí để tổ chức lại chuỗi tăng lên đáng kể. Chính điều đó mới là nền tảng để các giao thức phía trên có thể tin rằng khoản BTC đã thực sự được khóa.

Theo góc nhìn hiện tại của tôi, vấn đề không nằm ở việc Bitcoin chậm, điều đáng suy nghĩ hơn là giao diện gần như không kể cho người dùng biết họ đang chờ vì điều gì, mô hình niềm tin của hệ thống được xây dựng trên finality của Bitcoin nhưng thứ hiện lên trước mắt chỉ là một thanh tiến trình.

Tôi thử trên testnet nên có đủ thời gian để quan sát. Với người đang khóa một khoản Bitcoin thật cảm giác đó chắc sẽ rất khác. Có lẽ câu hỏi không phải làm sao để thời gian chờ ngắn hơn mà là làm sao để người dùng nhìn thấy ý nghĩa của chính khoảng thời gian họ đang chờ.
#baby $BABY @BabylonLabs_io

Có một thời gian tôi gần như mặc định rằng mỗi khi thị trường nói Bitcoin có thêm "utility", điều đó có nghĩa là BTC đã thực sự bắt đầu được sử dụng ở đâu đó trên mainnet. Tôi ít khi phân biệt giữa một thiết kế đã được chứng minh và một sản phẩm đã sẵn sàng vận hành với vốn thật.

Khoảng 2 giờ sáng vẫn chưa ngủ, tôi mở bảng điều khiển staking chỉ để xem lượng BTC của mình có thay đổi gì không. Kết quả thì đúng như dự đoán: không có gì cả, bitcoin vẫn được khóa theo đúng cơ chế staking của Babylon. Điều đó vốn không có gì bất ngờ.
Sau đó tôi để ý cụm "TBV mở ra utility cho BTC" xuất hiện khá dày dưới các bài viết về Babylon. Ban đầu tôi cũng nghĩ điều đó đồng nghĩa với việc BTC đã có thể được dùng làm tài sản thế chấp trên Aave.
Nhưng khi bỏ qua các bài đăng và đọc lại tài liệu cùng tiến độ triển khai tôi mới nhận ra mình đã hiểu nhanh hơn thực tế. Babylon mới đưa Trustless Bitcoin Vaults tích hợp với Aave V4 lên public testnet từ đầu tháng 6. Đây là bước xác thực về mặt kỹ thuật, chưa phải một giao thức đã sẵn sàng tiếp nhận tài sản thật.

Để đi tới mainnet, proposal vẫn phải hoàn thành quy trình governance của Aave bao gồm đánh giá rủi ro, oracle, giới hạn thanh lý và nhiều tham số khác. Điều khiến tôi suy nghĩ không phải là testnet hay mainnet mà là việc đôi khi thị trường đang phản ánh một tương lai đã được thiết kế xong, trong khi chuỗi vẫn đang chờ bước cuối cùng để biến thiết kế đó thành hiện thực.
#baby $BABY @BabylonLabs_io

Có một điều tôi từng xem là khá hiển nhiên khi nghĩ về các giao thức lending. Tôi luôn cho rằng lãi suất biến động theo cung cầu là lựa chọn gần như mặc định vì tài sản thế chấp và thanh khoản đều nằm trong cùng một môi trường thực thi. Khi mọi trạng thái được cập nhật liên tục, cách thiết kế đó có vẻ rất tự nhiên.

Trong lúc đọc tài liệu về Trustless Bitcoin Vaults của Babylon và tự mình trải nghiệm testnet, có một chi tiết khiến tôi phải dừng lại. BTC vẫn được khóa bằng các script native của Bitcoin thay vì được đưa vào một smart contract trên chain khác. Ban đầu tôi chỉ xem đây là một cách lưu ký an toàn hơn.

Càng đọc, tôi càng nhận ra mình đã nhìn vấn đề quá đơn giản. Khi tài sản vẫn ở trên Bitcoin, nhiều cơ chế mà DeFi thường xem là hiển nhiên không còn có thể áp dụng nguyên vẹn. Không phải chúng không làm được mà là chúng sẽ cần những giả định và thành phần phối hợp mới để vận hành.
Điều đó khiến tôi nghĩ nhiều hơn về các mô hình lending có thể được xây dựng trên TBV. Có lẽ một số thiết kế sẽ nghiêng về sự đơn giản và khả năng dự đoán hơn là tối ưu hiệu quả vốn. Đó không hẳn là giới hạn của Bitcoin mà là hệ quả của việc cố giữ nguyên trust model ban đầu.
Điều tôi vẫn còn băn khoăn không phải là mô hình nào tốt hơn mà là liệu khi lending native BTC phát triển đủ lớn, các nhà thiết kế sẽ tiếp tục bảo vệ triết lý này hay chấp nhận thêm những giả định niềm tin để đổi lấy hiệu quả tài chính cao hơn.
#baby $BABY @BabylonLabs_io

Trước đây tôi thường đánh giá một giao thức qua những lỗ hổng có thể dẫn đến mất tài sản. Nếu không có khả năng đánh cắp tiền hay chiếm quyền kiểm soát mạng tôi thường xem đó là những lỗi triển khai rồi sẽ sớm được khắc phục.

Nhưng khi đọc một advisory bảo mật và phần thảo luận trên GitHub của Babylon, có một chi tiết khiến tôi phải dừng lại. Một validator có thể gửi một Vote Extension mà trường block_hash bị bỏ qua. Chỉ một trường dữ liệu tưởng như rất nhỏ nhưng lại đủ để khiến các node khác gặp lỗi khi xác minh thông điệp nếu không xử lý trường hợp này đúng cách.

Ban đầu tôi nghĩ đây chỉ là một bug lập trình, sau đó tôi nhận ra mình đã nhìn quá nhiều vào hậu quả mà quên mất vị trí của nó trong hệ thống. Lỗi này không cho phép đánh cắp Bitcoin cũng không trực tiếp tạo ra một chain khác. Điều nó ảnh hưởng là tính sẵn sàng của mạng. Một validator có thể khiến tiến trình xác minh gặp runtime panic và nếu nhiều node cùng rơi vào trạng thái đó thì khả năng duy trì liveness của mạng sẽ bị ảnh hưởng.

Điều khiến tôi suy nghĩ hơn lại nằm ở chỗ khác. Babylon kế thừa tính bảo mật từ Bitcoin thông qua các cơ chế như timestamping và checkpoint nhưng toàn bộ lớp điều phối vẫn được hiện thực bằng phần mềm của chính Babylon. Theo góc nhìn hiện tại của tôi, đây mới là nơi đáng quan sát nhất. Có lẽ câu hỏi không phải là liệu Bitcoin có đủ an toàn hay không mà là implementation kết nối với Bitcoin sẽ trưởng thành nhanh đến mức nào khi hệ thống phải vận hành dưới áp lực thực tế.
#baby $BABY @BabylonLabs_io

Je suis entré dans Babylon avec une pensée assez naturelle : puisque le staking est ouvert, je peux y participer à tout moment dès que cela me convient. Mais cette pensée m’a presque fait manquer la Phase 1.

Après avoir relu attentivement la documentation, j’ai seulement alors ouvert le tableau de bord du staking et j’ai compris que le Cap 1 est limité à 1.000 BTC. Les dépôts sont traités dans l’ordre d’apparition des transactions sur la blockchain Bitcoin ; lorsque le cap est atteint, les transactions arrivant ensuite passent en état d’overflow.

Ce qui m’a frappé, c’est que cette limite se remplit plus vite que je ne l’avais imaginé. À partir de là, j’ai commencé à voir la notion de « ouvert » d’une autre manière. Babylon ouvre bien le staking, mais avec un mécanisme FCFS : le moment où vous rejoignez fait aussi partie des conditions pour pouvoir participer.

Ce qui m’intéresse, c’est que le problème ne vient pas du design de Babylon. Plus je lis, plus j’apprécie la façon dont ils utilisent le timelock natif de Bitcoin, plutôt que de s’appuyer sur un asset tokenisé (wrapped) ou sur une couche de confiance externe.

Plus je lis, plus je me dis que cette limite n’est rien de caché. Le cap avait déjà été annoncé auparavant, et la Phase 1 a été déployée par étapes.
Peut-être que ce que j’ai mal compris dès le début, c’était simplement mon propre niveau d’attente.
Je ne veux pas me précipiter : je veux lire attentivement avant d’agir. Mais dans un système dépendant de l’ordre des transactions sur Bitcoin, même une courte période peut faire une énorme différence.

Et la question à laquelle je pense encore est la suivante : dans un système permissionless, « ouvert à tout le monde » a-t-il encore le même sens quand le moment où vous arrivez détermine votre capacité à participer ?
#baby $BABY @BabylonLabs_io

Aujourd’hui, j’ai passé presque toute une soirée à disséquer, à relire les documents de Babylon pour me préparer à une tâche sur CreatorPad, mais ce qui m’a fait m’arrêter n’est pas le mécanisme des Trustless Bitcoin Vaults. Ce qui m’a davantage fait réfléchir, en revanche, c’est l’écart entre les timelines des différents composants du système.

Au début, je tenais assez par défaut que le vault était une partie relativement aboutie, et que le Bitcoin Staking n’était qu’une étape de départ. Mais en recoupant davantage le whitepaper, les documents mis à jour et la FAQ, je me suis rendu compte que l’image semblait presque l’inverse.

Le Bitcoin Staking a connu plusieurs phases de développement et constitue aujourd’hui la partie la plus mature de Babylon, avec une quantité très importante de BTC staké sur le mainnet. Tandis que les Trustless Bitcoin Vaults, qui visent à faire du BTC natif une garantie (collatéral) pour les nouvelles DeFi, en sont seulement au stade public testnet. Un détail que j’ai aussi mal compris est que chaque vault ne fonctionne pas comme un pool de liquidité global, mais qu’il est conçu selon un modèle self-custodial pour chaque utilisateur.

Cela m’amène à me demander si, parfois, j’ai inconsciemment assimilé le degré de maturité du protocole de staking au niveau de préparation des Trustless Bitcoin Vaults. Peut-être que cet écart est tout à fait normal dans le développement du produit, mais je suis tout de même curieux de savoir comment il sera comblé lorsque TBV se rapprochera du mainnet.
#baby $BABY @BabylonLabs_io

Trước đây tôi vẫn nghĩ một thiết kế mới nên được kiểm chứng ở môi trường đơn giản trước. Ít biến số hơn, ít áp lực hơn rồi sau đó mới mở rộng sang những hệ sinh thái lớn hơn.

Nhưng khi đọc lại tài liệu về Trustless Bitcoin Vaults có một chi tiết khiến tôi phải dừng lại. Tích hợp DeFi đầu tiên của TBV lại là Aave v4 trên Ethereum.

Ban đầu tôi cho rằng đây chỉ là một lựa chọn về mặt hệ sinh thái. Càng đọc, tôi càng thấy có lẽ mình đã nhìn vấn đề theo hướng khác. Ethereum hiện vẫn là nơi tập trung phần lớn thanh khoản lending và lượng người dùng DeFi thực sự. Nếu muốn kiểm chứng rằng BTC gốc có thể tham gia hoạt động vay mượn mà không cần Wrapped BTC, bridge hay bên giám hộ thì đây là một môi trường đủ khắt khe để quan sát cách thiết kế đó vận hành trong thực tế.

Theo góc nhìn hiện tại của tôi, điều đáng chú ý không phải việc Babylon chọn Ethereum. Điều khiến tôi suy nghĩ hơn là họ bắt đầu bằng một thị trường đã có thanh khoản và kỳ vọng rất cao thay vì một môi trường dễ tạo cảm giác thành công.

Hôm nay tôi xem lại toàn bộ luồng TBV và đối chiếu với những gì mình từng ghi chú trước đây. Điều khiến tôi chú ý không phải mức lãi suất mà là việc BTC vẫn được khóa trên mạng Bitcoin theo các điều kiện đã được xác định sẵn thay vì phải được bọc hoặc chuyển qua một mô hình giám hộ khác.

Có lẽ điều còn đáng suy nghĩ không phải là Ethereum có phải điểm khởi đầu tốt nhất hay không mà là liệu một thiết kế chỉ thực sự có giá trị khi nó được kiểm chứng ngay trong môi trường khó nhất.
#baby $BABY @BabylonLabs_io

Ban đầu tôi cũng nghĩ điều đáng chú ý nhất ở Babylon là khả năng cho phép Bitcoin tham gia staking nhưng càng đọc tài liệu tôi càng thấy đó chỉ là lớp bề mặt của cả thiết kế.

Điều khiến tôi phải xem lại cách nhìn của mình là Babylon không yêu cầu bridge BTC sang một blockchain khác cũng không dựa vào wrapped BTC hay một bên lưu ký đáng tin cậy. Bitcoin vẫn được khóa trên chính mạng Bitcoin theo mô hình tự lưu ký. Điều được "đưa vào cuộc chơi" không phải quyền sở hữu Bitcoin mà là cam kết kinh tế gắn với lượng BTC đã stake. Nếu một validator hành xử sai, cơ chế của Babylon mới tạo điều kiện để áp dụng hình phạt kinh tế.

Theo góc nhìn hiện tại của tôi, giá trị của Babylon không nằm ở việc bổ sung thêm một hình thức staking. Điều thú vị hơn là cách họ cho phép các mạng Proof-of-Stake kế thừa economic security từ Bitcoin mà không cần thay đổi các giả định cốt lõi về quyền sở hữu và mô hình bảo mật của Bitcoin. Khi đó, Bitcoin không còn chỉ là một tài sản lưu trữ giá trị mà còn có thể trở thành nền tảng bảo mật kinh tế cho các hệ thống khác.

Thị trường thường chú ý đến những gì có thể đo lường ngay lập tức. Nhưng các lớp phối hợp hạ tầng thường chỉ bộc lộ giá trị khi chúng dần thay đổi cách người khác xây dựng hệ thống. Có lẽ điều Babylon đang thử nghiệm không phải là một mô hình staking mới mà là một cách để các blockchain khác tận dụng bảo mật kinh tế của Bitcoin mà vẫn giữ nguyên bản chất của chính Bitcoin.
#baby $BABY @BabylonLabs_io

Trước đây tôi gần như mặc định rằng staking luôn đồng nghĩa với việc đưa tài sản vào một hệ thống khác. Muốn tài sản tạo ra giá trị bảo mật thì phải chấp nhận chuyển quyền kiểm soát hoặc ít nhất là đặt niềm tin vào một lớp hạ tầng mới. Tôi đã quen nhìn hầu hết các mô hình staking theo cách đó.

Đến khi đọc tài liệu của Babylon có một chi tiết khiến tôi phải dừng lại. Điều làm tôi chú ý không phải khái niệm Bitcoin Staking mà là việc Bitcoin vẫn được khóa trên chính mạng Bitcoin thay vì phải bridge sang một blockchain khác. Tôi phải đọc thêm phần mô tả về timelock, EOTS và cơ chế slashing mới thấy ý tưởng này không đơn giản như tôi nghĩ.

Ban đầu tôi cho rằng Babylon chỉ đang tìm cách để Bitcoin tham gia bảo mật cho các mạng PoS. Sau đó tôi nhận ra trọng tâm không nằm ở việc di chuyển Bitcoin mà ở cách giá trị kinh tế của Bitcoin có thể được dùng để bảo vệ một hệ thống khác trong khi mô hình tự lưu ký vẫn được giữ nguyên. Theo góc nhìn hiện tại của tôi, sự khác biệt thực sự nằm ở nỗ lực tách asset custody khỏi economic security thay vì coi hai khái niệm đó luôn phải đi cùng nhau.
Điều đó khiến tôi suy nghĩ lại về trust model. Babylon dường như không cố thay đổi Bitcoin mà thay đổi cách các mạng khác tận dụng những thuộc tính bảo mật vốn đã tồn tại của Bitcoin. Trách nhiệm được phân tách lại còn giả định niềm tin cũng dịch chuyển theo.
Tôi vẫn cảm thấy mình chưa hiểu hết mọi hệ quả của thiết kế này. Có lẽ câu hỏi đáng suy nghĩ hơn không phải Bitcoin đang bảo vệ mạng nào mà là một hệ thống thực sự đang lựa chọn đặt niềm tin vào điều gì.
#baby $BABY @BabylonLabs_io

Auparavant, je voyais la mise en circulation des stablecoins comme une histoire de garanties et d’émetteurs. Tant qu’il y avait des actifs suffisamment sûrs et un mécanisme de liquidation approprié, le reste n’était qu’une question d’exécution. Je n’avais quasiment jamais remis en question cette hypothèse.

En lisant la documentation de Babylon, un détail m’a obligé à ralentir. Le Trustless Bitcoin Vault ne cherche pas à transformer le Bitcoin en stablecoin, et il ne retire pas non plus le BTC du Bitcoin de la manière que beaucoup de modèles de bridge ont déjà fait. Au lieu de cela, il propose une autre façon pour que le BTC participe à des applications financières tout en conservant les conditions de contrôle définies à l’avance. Cela m’a fait relire la partie conception plus d’une fois.
Au départ, je pensais que ce n’était qu’une forme de custody améliorée. Ensuite, j’ai compris que l’essentiel ne réside pas dans la question de savoir qui détient les actifs, mais dans le fait que les conditions d’utilisation et de déblocage du BTC ont été garanties dès le début et peuvent être vérifiées. À mon point de vue actuel, la différence réelle tient davantage à la réduction de la dépendance à un dépositaire qu’à l’élimination totale de la confiance dans le système.
Plus j’avance dans la lecture, plus je vois que cette conception reflète une autre hypothèse. Les stablecoins ont peut-être besoin non seulement de collatéral, mais aussi d’un modèle de contrôle qui réduit le rôle des intermédiaires de custody. La confiance ne disparaît pas : elle passe d’une organisation à des règles et à des hypothèses propres au protocole.

Je me demande encore si la valeur la plus grande du Trustless Bitcoin Vault réside dans sa fonctionnalité elle-même ou dans la manière dont il nous pousse à reconsidérer où un système de stablecoin place réellement sa confiance.
#baby $BABY @BabylonLabs_io

Auparavant, je partais presque par défaut du principe que Bitcoin ne prend vraiment tout son sens qu’en étant en dehors de toute logique de la DeFi. Plus il dépend peu d’autres systèmes, plus il conserve les hypothèses de sécurité initiales. Je le voyais comme une contrainte naturelle plutôt que comme un problème à résoudre.

En lisant la documentation de Babylon, il y a un détail qui m’a fait m’arrêter assez longtemps. Ils ne commencent pas par l’idée de transférer le BTC vers une autre blockchain. La question qu’ils posent est de savoir si Bitcoin peut participer à des applications DeFi sans avoir recours à un bridge ni à une entité de custody centralisée. Cela diffère de la manière dont j’avais toujours tendance à l’imaginer.

Au départ, je pensais que le Trustless Bitcoin Vault n’était qu’une manière de concevoir un pont de façon plus rigoureuse ; puis j’ai réalisé que l’essentiel ne résidait pas dans le déplacement des actifs. J’ai dû relire plusieurs fois la partie sur la conception pour comprendre qu’ils s’efforçaient de préserver le modèle de confiance de Bitcoin, tout en ouvrant la possibilité d’utiliser le BTC comme collatéral. D’après mon angle de vue actuel, la vraie différence tient au fait que le système tente de réduire les hypothèses à placer du côté d’un intermédiaire, plutôt que de modifier Bitcoin lui-même.

Cela m’amène à réfléchir davantage à la philosophie de conception. Peut-être que Babylon ne fait pas qu’ajouter un nouveau primitive à la DeFi. Il cherche à redéfinir la manière dont les droits de propriété, d’utilisation et la confiance sont dissociés tout en restant dans le même système.

Je me demande encore si cette approche sera largement acceptée : la plus grande transformation se situerait-elle dans la DeFi elle-même, ou dans notre façon de comprendre l’intégration de Bitcoin à la DeFi tout en conservant ses hypothèses fondamentales.
#baby $BABY @BabylonLabs_io

Auparavant, je pensais souvent que, pour intégrer Bitcoin à des systèmes plus complexes, il fallait accepter qu’un acteur se trouve au milieu. Cela pourrait être un bridge, une entité de conservation, ou bien un ensemble de signataires qui se relaient pour détenir le contrôle.

En lisant la documentation de Babylon, un détail m’a fait ralentir. Ils ne commencent pas par chercher à étendre les capacités de Bitcoin. Au contraire, ils s’efforcent de faire en sorte que Bitcoin reste sur son propre réseau, tandis que les conditions d’utilisation futures sont déterminées dès le moment de création du vault.

Au départ, je me suis dit que le Trustless Bitcoin Vault n’était qu’un modèle de verrouillage de BTC destiné au staking. Puis j’ai compris que l’essentiel résidait dans la manière dont les sorties de dépense valides sont engagées dès le départ via la structure Taproot et des transactions préparées à l’avance, plutôt que de déléguer la prise de décision à une organisation ou à un groupe de personnes. J’ai dû relire plusieurs fois la section sur l’architecture pour réaliser que Babylon ne cherchait pas à rendre Bitcoin « plus intelligent ». Ils tentent simplement de réduire le nombre d’hypothèses que les utilisateurs sont forcés de devoir croire.

D’après mon point de vue actuel, ce qui est marquant ne se trouve pas dans le vault, mais dans la façon dont Babylon reconsidère le modèle de confiance. Le système conserve encore de nombreux rôles, mais ces rôles ne détiennent pas la garde de Bitcoin. Au lieu de croire qu’une entité se comportera toujours correctement, les utilisateurs s’appuient davantage sur des règles déjà engagées et que c’est Bitcoin lui-même qui exécute.

Peut-être la question la plus intéressante à se poser est-elle la suivante : lorsque tous les pouvoirs de contrôle sont ancrés par des règles dès le départ, modifie-t-on la manière dont on répartit la confiance, ou redéfinit-on simplement le sens même de « ne pas avoir besoin de croire » au sein d’un système.
#baby $BABY @BabylonLabs_io

Auparavant, je pensais qu’un système, pour valider une transaction, devait d’abord avoir accès à suffisamment de données. Cela semblait relever de l’évidence. Pour vérifier si quelque chose est vrai ou faux, il faut que quelqu’un ait le droit de consulter les informations pertinentes.

En relisant attentivement la documentation du Newton Protocol, j’ai remarqué un détail qui m’a fait m’arrêter. L’objectif de la conception ne consiste pas à valider plus rapidement, mais à prouver qu’une condition est remplie tout en limitant la divulgation de données sensibles. J’ai dû relire plusieurs fois les passages sur les Verifiable Credentials, les Zero Knowledge Proofs et l’architecture de protection des données.
Au départ, je pensais qu’il s’agissait simplement d’une manière de renforcer la confidentialité, mais j’ai ensuite réalisé que je regardais le problème trop étroitement. À mon point de vue actuel, l’important n’est pas d’où les données sont transmises ou stockées, mais que le système ne partage que ce qui est réellement nécessaire pour la vérification. La partie vérificatrice s’appuie sur des preuves ou des attestations vérifiables, plutôt que sur l’intégralité des données sources.

Cela m’a aussi amené à repenser le trust model. La confiance ne se concentre plus sur le fait qu’une partie est autorisée à voir les données ; elle se répartit entre des preuves cryptographiques, le réseau d’opérateurs et les garanties économiques du protocole. Je me demande encore si la plus grande nouveauté ici vient de la technologie, ou si elle tient plutôt à la façon dont nous définissons ce qui est « suffisant » pour pouvoir faire confiance.
#newt $NEWT @NewtonProtocol

Ce matin, j’ai lu une annonce à propos du programme Binance Wallet Booster de GRVT. La première chose qui a attiré mon attention n’est pas les 1,5 million de tokens, mais la mention « pas besoin de faire des transactions, pas besoin de déposer des actifs ». Au début, je me suis dit que ce n’était qu’une campagne d’onboarding assez classique.

Mais quand j’ai rouvert le document sur la Rewards Season 2, je me suis arrêté un instant. Le mécanisme de répartition des récompenses y est de nouveau lié à des activités reconnues sur la plateforme comme les transactions, le dépôt et le maintien d’actifs sur GRVT, la participation à des GRVT Strategies ou d’autres formes de contribution. Cette approche est assez différente du fait de simplement accomplir quelques tâches pour être éligible aux récompenses.

C’est à ce moment-là que j’ai compris que ce qui est intéressant ne se trouve pas dans deux programmes distincts, mais dans le fait qu’ils semblent traiter deux étapes différentes du même parcours utilisateur. D’un côté, on aide les utilisateurs à accéder à l’écosystème avec des barrières très faibles ; de l’autre, on les encourage à revenir et à utiliser, au fil du temps, les fonctionnalités de la plateforme.

Je ne considère pas encore cela comme une contradiction. Peut-être que ce sont simplement deux objectifs différents dans la même stratégie de croissance, mais ce qui continue à me faire réfléchir, c’est : après la fin des programmes d’incitation initiaux, combien de personnes continueront d’utiliser le produit uniquement pour l’expérience qu’il offre, plutôt que pour la seule récompense ?
#grvt @grvt_io

J’ai l’habitude de consulter le tableau des départs avant de partir pour l’aéroport, puis de le vérifier à nouveau dans le taxi, et une troisième fois après être entré dans le terminal. La plupart du temps, rien ne change. La porte d’embarquement est la même. L’heure est la même. J’avais déjà l’information. Je ne fais juste pas entièrement confiance à cette information tant que je n’en ai pas besoin, au moment où il faut vraiment l’utiliser.

Cela me trottait dans la tête pendant que je lisais au sujet du lancement de token de GRVT, le 21 juillet. Un TGE ressemble de l’extérieur à un événement unique, presque comme si quelqu’un actionnait un interrupteur. Mais plus je regardais le déroulement, moins cela me semblait être le cas.

Le token ne devient significatif que parce qu’une série de décisions a déjà été fixée avant le début des échanges. L’offre est définie. L’allocation est prédéterminée. Les utilisateurs s’inscrivent pour leur airdrop, choisissent s’ils doivent réclamer immédiatement ou différer via le mécanisme du Multiplier, et ces choix deviennent partie de l’état que le système doit respecter une fois que $GRVT sera en ligne. La cotation ne crée pas l’appropriation autant qu’elle expose une appropriation qui a déjà été prise en compte.

Au départ, je pensais que la partie difficile d’un TGE, c’était de gérer la demande du marché. Maintenant j’en suis moins sûr. Les marchés peuvent découvrir des prix par eux-mêmes. Le problème le plus ardu pourrait plutôt être de s’assurer que chaque solde, chaque allocation et chaque réclamation se résout exactement comme le protocole s’y était engagé avant même que quelqu’un ne commence à trader.

Je me demande encore si un TGE réussi consiste vraiment à lancer un token, ou à prouver que toutes les hypothèses faites avant le lancement peuvent survivre à la première minute une fois qu’il est en ligne.
#grvt @grvt_io

Auparavant, je partais du principe que la limite des smart contracts résidait principalement dans leur capacité d’exprimer une logique. Si le contrat est suffisamment complexe, rédigé avec assez de rigueur et audité minutieusement, presque toutes les règles peuvent être mises en chaîne. J’étais habitué à envisager le problème sous cet angle depuis assez longtemps.

En relisant attentivement la documentation du protocole Newton, un détail m’a fait m’arrêter. Le projet ne cherche pas à faire en sorte que les smart contracts en fassent plus. Au lieu de cela, il sépare la partie décisionnelle de la partie d’exécution. Au début, j’ai pensé que ce n’était qu’une manière d’organiser l’architecture, mais plus je lisais, plus je me rendais compte que j’avais mal compris l’essentiel.

D’après mon point de vue actuel, le vide ne réside pas dans le fait que les smart contracts manquent de fonctionnalités. Ce qui leur manque, c’est la capacité à gérer des décisions qui dépendent d’un contexte en constante évolution tout en conservant des limites vérifiables. Les smart contracts sont très bons pour exécuter ce qui est connu, mais ils ne sont pas conçus pour évaluer eux-mêmes ce qui n’apparaît que lorsque le système est en fonctionnement.

Cela m’a amené à repenser le modèle de répartition des responsabilités. Peut-être que l’on n’a jamais attendu des smart contracts qu’ils contiennent toute la logique : ils devraient plutôt servir à confirmer le résultat d’un processus de décision dont on peut vérifier le bien-fondé.

Je me demande encore si cette approche élargit réellement les capacités des smart contracts, ou si elle ne fait en réalité que redéfinir le rôle qu’ils auraient dû assumer dès le départ.
#newt $NEWT @NewtonProtocol