DannyVN

Một giả định mình thấy rất phổ biến khi nhiều người nhắc đến Sign Protocol gần đây trên Binance Square: miễn là dữ liệu đã được ký và chứng thực đúng chuẩn, thì toàn bộ quy trình phía sau có thể vận hành mà không cần đặt thêm niềm tin vào bất kỳ bên nào tạo ra dữ liệu đó. Giả định này nghe rất gần với tinh thần zero-trust, bởi khi mọi thứ đều có thể kiểm tra, ta dễ nghĩ rằng niềm tin đã bị loại bỏ khỏi hệ thống.
Nhưng khi đi vào cách Sign thực sự được sử dụng, mình bắt đầu nhận ra một điểm lệch nhỏ nhưng quan trọng. Sign không cố gắng đảm bảo rằng mọi chứng thực là đúng, mà nó cung cấp một cách để buộc quy trình phải vận hành dựa trên những điều kiện đã được định nghĩa từ trước, khiến cho việc “tin” hay “không tin” không còn là yếu tố quyết định việc hệ thống có chấp nhận một trạng thái hay không.
Điểm mấu chốt nằm ở cách Sign định nghĩa schema, bởi trong hệ thống này, mỗi chứng thực luôn gắn với một schema cụ thể, và schema không chỉ đơn thuần là khuôn dạng dữ liệu mà còn là một tập hợp các ràng buộc về ý nghĩa, quy định rõ dữ liệu gồm những trường gì, thuộc loại nào, và trong nhiều trường hợp phải liên kết với những chứng thực nào khác thì mới được coi là hợp lệ. Khi schema được định danh rõ ràng và có thể tham chiếu lại, mình nhận ra rằng việc tạo ra một chứng thực không còn là hành động tùy ý, mà trở thành một quá trình phải tuân theo một khuôn đã được công bố, và bất kỳ ai cũng có thể kiểm tra xem nó có thực sự nằm trong khuôn đó hay không.
Nhưng phần quan trọng hơn nằm ở cách các chứng thực liên kết với nhau. Trong Sign, một chứng thực không chỉ tồn tại như một bản ghi độc lập, mà thường chứa tham chiếu đến các chứng thực trước đó thông qua các định danh cụ thể, từ đó hình thành nên một chuỗi phụ thuộc rõ ràng. Khi nhìn vào cấu trúc này, mình thấy rằng một bước sau trong quy trình không “tin” rằng bước trước đã làm đúng, mà yêu cầu phải có bằng chứng rằng bước trước đã tồn tại dưới đúng schema, được tạo ra bởi một bên phù hợp, và được liên kết đúng cách trong toàn bộ cấu trúc dữ liệu.
Điều này khiến cách vận hành của quy trình thay đổi theo một hướng rất cụ thể. Thay vì dựa vào giả định rằng bước trước là hợp lệ, mỗi bước chỉ cần kiểm tra xem các điều kiện đã được định nghĩa có được thỏa mãn hay chưa, và nếu thiếu một trong các điều kiện đó, trạng thái tương ứng đơn giản là không được chấp nhận. Với mình, zero-trust trong Sign vì vậy không nằm ở việc liên tục đi xác minh con người hay tổ chức, mà nằm ở việc thiết kế dữ liệu và mối quan hệ giữa dữ liệu sao cho những gì không thỏa điều kiện không thể được sử dụng như một trạng thái hợp lệ trong hệ thống.
Với mình, cách nhìn gọn nhất về Sign Protocol là: nó biến niềm tin thành các điều kiện có thể kiểm tra, và toàn bộ quy trình chỉ còn là việc các điều kiện đó có được thỏa mãn hay không.
Tuy nhiên, có một điểm mình thấy cần làm rõ để tránh hiểu nhầm rằng Sign tự động thực thi toàn bộ logic này. Bản thân Sign không chặn việc tạo ra một chứng thực “sai”, bởi bất kỳ ai cũng có thể tạo chứng thực miễn là tuân theo schema, và việc một chứng thực có được chấp nhận hay không phụ thuộc vào bên sử dụng dữ liệu, thường là các hợp đồng thông minh hoặc ứng dụng đọc dữ liệu từ Sign. Chính tại lớp này, mình nhận ra rằng các điều kiện mới được kiểm tra một cách đầy đủ, và nếu một ứng dụng chọn kiểm tra chặt chẽ schema, bên phát hành và toàn bộ chuỗi tham chiếu, thì quy trình đó mới thực sự vận hành theo hướng zero-trust.
Điều này dẫn đến một hệ quả quan trọng là cùng một tập chứng thực trong Sign, hai ứng dụng khác nhau có thể đưa ra hai kết quả khác nhau, chỉ vì chúng chọn cách kiểm tra khác nhau. Nhìn từ góc độ này, mình thấy rằng zero-trust không phải là thuộc tính mặc định của Sign, mà là một cách sử dụng Sign, nơi các điều kiện được kiểm tra đầy đủ và nhất quán để loại bỏ nhu cầu phải tin vào từng bước trung gian.
Khi các điều kiện này được thực thi một cách nghiêm ngặt, toàn bộ các chứng thực sẽ tạo thành một cấu trúc có thể kiểm chứng lại, nơi bất kỳ ai cũng có thể lần ngược từ trạng thái hiện tại về các chứng thực ban đầu và kiểm tra xem toàn bộ chuỗi điều kiện có thực sự nhất quán hay không. Trong trường hợp này, với mình, việc kiểm tra không còn là một bước tách biệt, mà trở thành một phần tự nhiên của cách hệ thống vận hành.
Nhưng đến đây, một giới hạn quan trọng bắt đầu xuất hiện. Sign đảm bảo rằng quy trình tuân thủ đúng các điều kiện đã được định nghĩa, nhưng nó không đảm bảo rằng dữ liệu ban đầu là đúng, bởi nếu một chứng thực gốc chứa thông tin sai nhưng vẫn đúng schema và được ký hợp lệ, toàn bộ các bước phía sau vẫn có thể tiếp tục mà không gặp trở ngại nào. Điều này khiến mình nhận ra rằng zero-trust trong Sign không nhằm xác định sự thật tuyệt đối, mà nhằm đảm bảo rằng mọi trạng thái đều là kết quả của một chuỗi điều kiện có thể kiểm chứng.
Và từ đó, một sự thay đổi tinh tế trong cách hiểu về niềm tin bắt đầu xuất hiện. Niềm tin không biến mất khỏi hệ thống, mà bị thu hẹp lại thành những điểm cụ thể hơn như bên phát hành ban đầu hoặc cách schema được thiết kế, khiến cho toàn bộ phần còn lại của quy trình không còn phụ thuộc vào việc “tin” hay “không tin” từng bước riêng lẻ. Khi số lượng schema và mối liên kết tăng lên, mình thấy rằng việc tự mình kiểm tra toàn bộ cấu trúc trở nên khó khăn, và các lớp trung gian bắt đầu xuất hiện để tổng hợp và diễn giải dữ liệu, từ đó đưa niềm tin quay trở lại nhưng ở một vị trí khác.
Có lẽ vì vậy, cách hiểu chính xác hơn về Sign không phải là loại bỏ niềm tin, mà là biến niềm tin thành những giả định cụ thể, có thể nhìn thấy, có thể kiểm tra, và có thể tách rời khỏi nhau trong từng ngữ cảnh sử dụng. Và nếu nhìn xa hơn một chút, mình bắt đầu tự hỏi rằng khi một hệ thống như Sign cho phép biểu diễn toàn bộ quy trình bằng các điều kiện và mối liên kết dữ liệu như vậy, liệu blockchain trong tương lai sẽ còn là nơi lưu trữ trạng thái, hay sẽ dần trở thành một hạ tầng nơi trạng thái chỉ đơn thuần là kết quả của việc thỏa mãn những điều kiện đã được định nghĩa từ trước.
$SIGN #SignDigitalSovereignInfra @SignOfficial

Mi sono fermato a lungo a leggere la parte della documentazione del Sign Protocol che dice che l'attestazione dovrebbe essere "insightful", non solo dati grezzi. A prima vista, sembra che i dati passando attraverso il Sign diventino più utili e contestualizzati. Ma se si guarda attentamente a come l'attestazione è realmente costituita, l'assunzione che l'insight sia già presente in essa inizia a non reggere.
Sign consente di definire uno schema per strutturare i dati, associare l'attestazione all'emittente tramite una firma, e mantenere l'intero ciclo di vita per poter tracciare e verificare. Questo rende i dati più chiari dal punto di vista strutturale e più affidabili dal punto di vista dell'integrità. Ma lo schema non codifica il significato semantico, e l'attestazione non contiene alcuna logica di esecuzione per trasformare i dati in conclusioni. È solo dati, firma e stato.

Il modo più veloce per comprendere SIGN Stack non è guardare ciascun componente.
Ma è provare a rimuovere una parte e vedere se il sistema rimanente può ancora funzionare.
E questo è anche il momento in cui mi sono reso conto del perché Sign Protocol non possa essere compreso come un protocollo separato.
SIGN Stack è progettato come un sistema interdipendente, dove i tre componenti non si integrano l'uno con l'altro, ma si vincolano.
Valuta Digitale - Infrastruttura Stablecoin, Sign Protocol e TokenTable non sono tre opzioni. Sono tre condizioni per l'esistenza del sistema.

La Crypto non manca di prodotti. Mancano le accettazioni da parte del governo. Ed è per questo che la maggior parte dei sistemi onchain si concentra ancora su cicli familiari come DeFi, trading, speculazione.
Il Sign Protocol sceglie di andare dritto al punto critico. Non con la costruzione di un ulteriore prodotto. Ma costruendo per le stesse parti che controllano il mondo reale.
Sin dall'inizio, Sign non ha seguito la direzione B2B. Hanno puntato direttamente al B2G (Business-to-Government). Questo sembra andare contro lo spirito iniziale della crypto.

Quando guardo come il Sign Protocol affronta l'identità, non inizio dalla tecnologia. Inizio da una domanda più semplice:
Se ogni paese ha già un sistema di identità, cosa sta realmente cercando di 'costruire' Sign?
La maggior parte delle strategie di ID digitale presuppone spesso che si possa ricominciare da capo. Un nuovo database, un nuovo sistema, un'integrazione e il gioco è fatto.
Ma la realtà non funziona in questo modo.

Ho letto la parte sul Dual CBDC del Sign Protocol e mi sono fermato a lungo quando ho visto che separano nettamente wholesale e retail in due namespace distinti, ciascuno con una politica di approvazione diversa. All'inizio pensavo che il CBDC dovesse essere solo veloce, sicuro e trasparente. Ma Sign dimostra che questa implementazione è molto più sofisticata e solleva al contempo una domanda difficile: massima trasparenza, ma l'accesso è sufficiente?
A livello wholesale CBDC (wCBDC), il Sign Protocol opera nel namespace wholesale con una politica di approvazione separata per le transazioni interbancarie. Le banche possono effettuare grandi liquidazioni interbancarie, con trasparenza a livello RTGS – ovvero ogni transazione è registrata in modo trasparente come nel sistema di pagamento netto tradizionale in tempo reale, con finalità immediata. La gestione delle riserve è integrata direttamente con la banca centrale. Ciò significa che qualsiasi grande transazione tra istituzioni finanziarie non può essere modificata, con una traccia di audit perfetta.

Una transazione CBDC può essere confermata come valida senza che nessuno al di fuori delle persone coinvolte conosca l'importo.
Questo è il tipo di sistema che @SignOfficial sta sperimentando con implementazioni permissioned basate su Hyperledger Fabric.
Sembra ragionevole. Ma è anche il momento in cui le cose iniziano a complicarsi.
Non si tratta di nascondere tutto. Ma solo di rivelare ciò che deve essere rivelato.
In teoria, le CBDC sono sempre bloccate tra due estremi. Da un lato ci sono la trasparenza come RTGS, dove le banche vedono tutto. Dall'altro lato c'è la privacy come il contante, dove nessuno vede nulla al di fuori delle persone coinvolte. La maggior parte dei sistemi sceglie un punto a metà strada.

Negli ultimi giorni ho dedicato abbastanza tempo a leggere documenti @MidnightNetwork e ho trovato un interesse insolito. Non è il tipo di interesse che si prova quando si vede un progetto che parla di privacy, ma è una forma di... leggera sospettosità. Perché l'argomento che affrontano è troppo familiare, ma il modo in cui si avvicinano mi fa dubitare se stia realmente comprendendo.
Nel crypto, la storia sulla privacy è stata raccontata molte volte. La maggior parte segue una direzione simile. La blockchain è trasparente, chiunque può leggere i dati, auditare tutto. Se è necessaria riservatezza, allora si aggiunge uno strato di protezione sopra. Nascondere l'indirizzo, offuscare i dati, o utilizzare zero-knowledge per ridurre la quantità di informazioni rivelate. Questa narrativa è abbastanza pulita. La trasparenza è la norma, la privacy è un'aggiunta.

Non è stato vano il mio approfondimento su @SignOfficial , ho cominciato a rendermi conto di una cosa piuttosto strana: potrebbe essere che fossi abituato a guardare la blockchain dal punto sbagliato. Di solito penso a dove i dati sono memorizzati, o dove il sistema è implementato, prima di pensare a come quei dati vengono verificati.
Con Sign, quell'ordine è quasi invertito.
Se la possibilità di verifica può esistere come un livello indipendente, allora la domanda non è più quale chain contiene i dati, ma se può essere dimostrata in un modo che altri sistemi accettano. E da quel punto di vista, ho cominciato a rivedere i sistemi blockchain nel contesto del governo.

Leggendo di @SignOfficial , non mi sembra difficile da capire, ma è la differenza rispetto ai metodi di sicurezza comunemente visti nel crypto."
Il mercato ha una narrativa piuttosto familiare: se vuoi costruire un sistema affidabile, devi controllare la sicurezza dall'inizio alla fine. È meglio avere una propria catena, avere i propri validatori, avere meccanismi propri. In breve, maggiore è l'autonomia della sicurezza, meglio è. Questo sembra molto ragionevole, soprattutto quando si parla di sistemi al servizio del governo o delle imprese.