Rythm - Crypto Analyst
Investor focused on Crypto, Gold & Silver.
I look at liquidity, physical markets, and macro shifts — not headlines.
Here to share how I see cycles play out.
Deținător U
Trader de înaltă frecvență
8.3 Ani
111 Urmăriți
359 Urmăritori
878 Apreciate
87 Distribuite
Postări
Toate
Citate
Vedeți traducerea
Khi infrastructure danh tính trở thành công cụ chính sách
Mình bắt đầu nhìn Sign Protocol khác đi sau khi đọc một báo cáo về cách Belarus dùng hệ thống nhận diện khuôn mặt để theo dõi người biểu tình năm 2020. Không phải vì Sign đang làm điều tương tự. Mà vì báo cáo đó đặt ra một câu hỏi mình chưa thấy ai hỏi thẳng về Sign: khi một chính phủ kiểm soát tầng phát hành credential, họ kiểm soát thứ gì thực sự?
Câu trả lời không phải dữ liệu. Câu trả lời là quyền truy cập.
Sign đang triển khai sovereign infrastructure ở Kyrgyzstan, Sierra Leone, UAE. Mô hình vận hành là chính phủ làm issuer: họ phát hành credential danh tính cho công dân, credential đó được dùng để truy cập dịch vụ tài chính, thanh toán, và trong tương lai có thể là CBDC. Sign ghi nhận và thực thi những credential đó trên chain, nơi chúng không thể bị xóa hay sửa đổi.
Đây là chỗ infrastructure trung lập bắt đầu không còn trung lập nữa.
Trong hệ thống truyền thống, chính phủ kiểm soát quyền truy cập dịch vụ thông qua giấy tờ, database, và bureaucracy — những thứ có thể bị challenge, có thể bị leak, có thể bị thay thế. Khi Sign trở thành infrastructure quốc gia, chính phủ kiểm soát quyền truy cập thông qua credential on-chain mà Sign thực thi tự động và không thể đảo ngược.
Đây là “credential as policy lever”. Credential không còn chỉ là bằng chứng danh tính. Nó trở thành công cụ thực thi chính sách và blockchain làm cho việc thực thi đó trở nên tự động, không cần trung gian, và không thể bị override.
Hãy hình dung một scenario không phải giả thuyết: năm 2026, chính phủ Kyrgyzstan quyết định một nhóm dân tộc thiểu số cụ thể bị loại khỏi chương trình Digital Som vì lý do "an ninh quốc gia." Trong hệ thống truyền thống, quyết định đó có thể bị challenge qua tòa án, bị báo chí đưa tin, bị áp lực quốc tế. Trong hệ thống Sign, quyết định đó được thực thi ở tầng credential: issuer đơn giản là không cấp hoặc revoke credential cho nhóm đó, và toàn bộ hệ thống tài chính số của họ bị tắt tự động.
Không cần lệnh tòa án. Không cần database admin. Không cần giải thích. Chỉ cần một thay đổi ở tầng issuer.
Mình không nói Kyrgyzstan sẽ làm điều đó. Mình đang nói hệ thống được thiết kế theo cách cho phép điều đó xảy ra mà không có bất kỳ friction nào.
Đây không phải lỗi của Sign. Sign đang build sovereign infrastructure theo đúng định nghĩa của từ đó — infrastructure do sovereign state kiểm soát. Vấn đề là "sovereign" trong crypto thường được hiểu là tự chủ khỏi tập đoàn hay tổ chức tư nhân. Nhưng sovereign deployment thực tế có nghĩa là chính phủ có toàn quyền kiểm soát, và không phải chính phủ nào cũng có cơ chế kiểm soát quyền lực tương đương nhau.
Sign đang triển khai ở các quốc gia có chỉ số pháp quyền rất khác nhau. Kyrgyzstan xếp hạng 122/142 trong Rule of Law Index 2023. Sierra Leone xếp 109/142. UAE xếp 50/142. Cùng một infrastructure, ba môi trường pháp lý hoàn toàn khác nhau.
Credential as policy lever không nguy hiểm trong một nhà nước pháp quyền mạnh với cơ chế kiểm soát và cân bằng quyền lực rõ ràng. Nó trở thành attack surface chính trị trong môi trường mà issuer không có accountability mechanism thật sự.
Sign có thể lập luận rằng họ chỉ là infrastructure và không chịu trách nhiệm về cách chính phủ dùng infrastructure đó. Lập luận đó đúng về mặt pháp lý và kỹ thuật. Nhưng nó không làm mất đi thực tế rằng Sign đang làm cho việc thực thi chính sách exclusionary trở nên dễ dàng và tự động hơn bất kỳ hệ thống nào trước đó.
Thứ làm Sign khác với một database chính phủ thông thường là tính bất biến. Khi credential bị revoke hay không được cấp, quyết định đó được ghi vào một hệ thống mà không ai có thể sửa đổi — kể cả tòa án, kể cả chính phủ kế nhiệm, kể cả Sign. Đó là thứ mà Sign marketing như một feature. Trong một sovereign deployment với accountability thấp, đó là một risk.
Đó cũng là lý do mình theo dõi Sign không qua số lượng quốc gia ký kết mà qua một câu hỏi cụ thể hơn: nếu một công dân bị từ chối credential hoặc bị thu hồi, họ có chỗ nào để appeal không, và chỗ đó có độc lập với chính phủ đang kiểm soát hệ thống không?
Sign không quyết định ai được dùng hệ thống. Chính phủ quyết định.
Sign chỉ làm một việc: biến quyết định đó thành trạng thái không thể đảo ngược và để toàn bộ hệ thống tự động thực thi nó.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Câu trả lời không phải dữ liệu. Câu trả lời là quyền truy cập.
Sign đang triển khai sovereign infrastructure ở Kyrgyzstan, Sierra Leone, UAE. Mô hình vận hành là chính phủ làm issuer: họ phát hành credential danh tính cho công dân, credential đó được dùng để truy cập dịch vụ tài chính, thanh toán, và trong tương lai có thể là CBDC. Sign ghi nhận và thực thi những credential đó trên chain, nơi chúng không thể bị xóa hay sửa đổi.
Đây là chỗ infrastructure trung lập bắt đầu không còn trung lập nữa.
Trong hệ thống truyền thống, chính phủ kiểm soát quyền truy cập dịch vụ thông qua giấy tờ, database, và bureaucracy — những thứ có thể bị challenge, có thể bị leak, có thể bị thay thế. Khi Sign trở thành infrastructure quốc gia, chính phủ kiểm soát quyền truy cập thông qua credential on-chain mà Sign thực thi tự động và không thể đảo ngược.
Đây là “credential as policy lever”. Credential không còn chỉ là bằng chứng danh tính. Nó trở thành công cụ thực thi chính sách và blockchain làm cho việc thực thi đó trở nên tự động, không cần trung gian, và không thể bị override.
Hãy hình dung một scenario không phải giả thuyết: năm 2026, chính phủ Kyrgyzstan quyết định một nhóm dân tộc thiểu số cụ thể bị loại khỏi chương trình Digital Som vì lý do "an ninh quốc gia." Trong hệ thống truyền thống, quyết định đó có thể bị challenge qua tòa án, bị báo chí đưa tin, bị áp lực quốc tế. Trong hệ thống Sign, quyết định đó được thực thi ở tầng credential: issuer đơn giản là không cấp hoặc revoke credential cho nhóm đó, và toàn bộ hệ thống tài chính số của họ bị tắt tự động.
Không cần lệnh tòa án. Không cần database admin. Không cần giải thích. Chỉ cần một thay đổi ở tầng issuer.
Mình không nói Kyrgyzstan sẽ làm điều đó. Mình đang nói hệ thống được thiết kế theo cách cho phép điều đó xảy ra mà không có bất kỳ friction nào.
Đây không phải lỗi của Sign. Sign đang build sovereign infrastructure theo đúng định nghĩa của từ đó — infrastructure do sovereign state kiểm soát. Vấn đề là "sovereign" trong crypto thường được hiểu là tự chủ khỏi tập đoàn hay tổ chức tư nhân. Nhưng sovereign deployment thực tế có nghĩa là chính phủ có toàn quyền kiểm soát, và không phải chính phủ nào cũng có cơ chế kiểm soát quyền lực tương đương nhau.
Sign đang triển khai ở các quốc gia có chỉ số pháp quyền rất khác nhau. Kyrgyzstan xếp hạng 122/142 trong Rule of Law Index 2023. Sierra Leone xếp 109/142. UAE xếp 50/142. Cùng một infrastructure, ba môi trường pháp lý hoàn toàn khác nhau.
Credential as policy lever không nguy hiểm trong một nhà nước pháp quyền mạnh với cơ chế kiểm soát và cân bằng quyền lực rõ ràng. Nó trở thành attack surface chính trị trong môi trường mà issuer không có accountability mechanism thật sự.
Sign có thể lập luận rằng họ chỉ là infrastructure và không chịu trách nhiệm về cách chính phủ dùng infrastructure đó. Lập luận đó đúng về mặt pháp lý và kỹ thuật. Nhưng nó không làm mất đi thực tế rằng Sign đang làm cho việc thực thi chính sách exclusionary trở nên dễ dàng và tự động hơn bất kỳ hệ thống nào trước đó.
Thứ làm Sign khác với một database chính phủ thông thường là tính bất biến. Khi credential bị revoke hay không được cấp, quyết định đó được ghi vào một hệ thống mà không ai có thể sửa đổi — kể cả tòa án, kể cả chính phủ kế nhiệm, kể cả Sign. Đó là thứ mà Sign marketing như một feature. Trong một sovereign deployment với accountability thấp, đó là một risk.
Đó cũng là lý do mình theo dõi Sign không qua số lượng quốc gia ký kết mà qua một câu hỏi cụ thể hơn: nếu một công dân bị từ chối credential hoặc bị thu hồi, họ có chỗ nào để appeal không, và chỗ đó có độc lập với chính phủ đang kiểm soát hệ thống không?
Sign không quyết định ai được dùng hệ thống. Chính phủ quyết định.
Sign chỉ làm một việc: biến quyết định đó thành trạng thái không thể đảo ngược và để toàn bộ hệ thống tự động thực thi nó.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Vedeți traducerea
Sign nói với bạn rằng protocol này decentralized. Attestation trên nhiều chain, không ai kiểm soát, không có single point of failure.
Điều đó đúng ở lớp lưu trữ.
Nhưng khi bạn thật sự dùng Sign: query credential, verify attestation, build app trên Sign — bạn không đọc trực tiếp từ chain. Bạn đọc từ SignScan.
SignScan là indexer do Sign vận hành, đọc dữ liệu từ nhiều chain và trả về qua một API duy nhất. Nghe có vẻ là chi tiết kỹ thuật nhỏ. Nhưng trong thực tế, không có developer nào tự scan từng block trên từng chain. Tất cả đều dùng SignScan. Và mình mất khá lâu mới nhận ra điều đó có nghĩa gì: mọi app, mọi hệ thống verify credential qua Sign, đều đang phụ thuộc vào một service tập trung do Sign kiểm soát.
Đây là centralized indexing bottleneck: protocol decentralized ở tầng lưu trữ nhưng tập trung ở tầng query, và tầng query là thứ mọi người thật sự dùng.
Nếu SignScan down, credential vẫn tồn tại trên chain. Nhưng không ai verify được. Hệ thống quốc gia của Kyrgyzstan, national ID của Sierra Leone, toàn bộ ecosystem build trên Sign đều phụ thuộc vào một indexer hoạt động liên tục.
Sign Decentralized trên blockchain. Nhưng mọi người dùng đều đang đọc qua một server do Sign kiểm soát.
Mình nghĩ ai build production system trên Sign nên có fallback: đọc trực tiếp từ chain khi SignScan không response, dù chậm hơn và phức tạp hơn. Đây không phải best practice, đây là điều kiện tối thiểu để hệ thống không phụ thuộc hoàn toàn vào một service tập trung.
Đó cũng là lý do mình theo dõi uptime của SignScan chặt hơn uptime của bất kỳ blockchain nào mà Sign đang chạy trên đó.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Điều đó đúng ở lớp lưu trữ.
Nhưng khi bạn thật sự dùng Sign: query credential, verify attestation, build app trên Sign — bạn không đọc trực tiếp từ chain. Bạn đọc từ SignScan.
SignScan là indexer do Sign vận hành, đọc dữ liệu từ nhiều chain và trả về qua một API duy nhất. Nghe có vẻ là chi tiết kỹ thuật nhỏ. Nhưng trong thực tế, không có developer nào tự scan từng block trên từng chain. Tất cả đều dùng SignScan. Và mình mất khá lâu mới nhận ra điều đó có nghĩa gì: mọi app, mọi hệ thống verify credential qua Sign, đều đang phụ thuộc vào một service tập trung do Sign kiểm soát.
Đây là centralized indexing bottleneck: protocol decentralized ở tầng lưu trữ nhưng tập trung ở tầng query, và tầng query là thứ mọi người thật sự dùng.
Nếu SignScan down, credential vẫn tồn tại trên chain. Nhưng không ai verify được. Hệ thống quốc gia của Kyrgyzstan, national ID của Sierra Leone, toàn bộ ecosystem build trên Sign đều phụ thuộc vào một indexer hoạt động liên tục.
Sign Decentralized trên blockchain. Nhưng mọi người dùng đều đang đọc qua một server do Sign kiểm soát.
Mình nghĩ ai build production system trên Sign nên có fallback: đọc trực tiếp từ chain khi SignScan không response, dù chậm hơn và phức tạp hơn. Đây không phải best practice, đây là điều kiện tối thiểu để hệ thống không phụ thuộc hoàn toàn vào một service tập trung.
Đó cũng là lý do mình theo dõi uptime của SignScan chặt hơn uptime của bất kỳ blockchain nào mà Sign đang chạy trên đó.
@SignOfficial $SIGN #SignDigitalSovereignInfra
SIGN
Deținere
PNL cumulat
+0.06%
Vedeți traducerea
Sign: khi “hệ sinh thái tích hợp” thực ra không tích hợp?
Mình đã dùng TokenTable để distribute token cho một dự án DeFi. Mọi thứ chạy tốt. Sau đó khách hàng hỏi: "Chúng ta có thể gắn attestation từ Sign Protocol vào để verify danh tính người nhận không?" Câu hỏi hợp lý, vì Sign marketing ba sản phẩm như một hệ sinh thái thống nhất: Sign Protocol cho attestation danh tính, TokenTable cho phân phối token, và EthSign cho ký hợp đồng điện tử.
Mình bắt đầu đọc docs để tìm integration path.
Không có.
Không phải integration bị ẩn hay phức tạp. Docs của Sign viết thẳng: "TokenTable and EthSign are standalone products that use the same core primitives and can be integrated into S.I.G.N. deployments when appropriate." Không phải subsystem. Không phải native integration. Standalone products có thể kết hợp khi cần, nhưng không tự động kết nối với nhau.
Đây là perceived composability gap: Sign marketing ba sản phẩm như một hệ sinh thái tích hợp thống nhất, nhưng ở tầng kiến trúc, chúng là ba sản phẩm riêng biệt dùng chung một số building blocks nền tảng.
Tại sao mình nghĩ điều này quan trọng?
Khi một chính phủ quyết định dùng S.I.G.N. cho sovereign infrastructure, họ đang mua một "sovereign system architecture" theo cách Sign mô tả. Nhưng thực tế đó là 3 sản phẩm riêng biệt và chính phủ phải tự chịu trách nhiệm kết nối chúng lại thành một hệ thống hoàn chỉnh.
Sự khác biệt đó không nhỏ. Với một startup, kết nối ba sản phẩm riêng là việc bình thường. Với một chính phủ đang build national digital infrastructure cho hàng triệu công dân, lớp kết nối đó là thứ quyết định liệu hệ thống có vận hành được ở quy mô thực tế hay không.
Mình không nói Sign đang lừa dối. Docs viết rõ, ai đọc kỹ đều thấy. Vấn đề là marketing và whitepaper đang tạo ra một ấn tượng khác với thực tế kiến trúc. "S.I.G.N. is sovereign-grade digital infrastructure" nghe như một platform tích hợp. Nhưng S.I.G.N. trong docs được định nghĩa là "a system-level blueprint", một bản thiết kế, không phải một sản phẩm tích hợp sẵn.
Blueprint và integrated platform là hai thứ khác nhau hoàn toàn khi bạn phải implement ở cấp độ quốc gia.
Đây không phải lỗi kỹ thuật. Đây là khoảng cách giữa narrative và architecture. TokenTable đã distribute hơn 4 tỷ USD token cho hơn 40 triệu địa chỉ, con số đó là thật và ấn tượng. EthSign có user base thật. Sign Protocol đang được triển khai ở Kyrgyzstan và Sierra Leone. Mỗi sản phẩm đứng vững một mình.
Nhưng perceived composability gap có nghĩa là bất kỳ team nào đang evaluate Sign với kỳ vọng rằng ba sản phẩm này sẽ hoạt động liền mạch như một platform sẽ phải tự xây lớp kết nối đó. Và lớp kết nối cho sovereign infrastructure không phải thứ có thể làm trong một sprint.
Ai đang cân nhắc dùng Sign cho sovereign deployment cần hỏi một câu trước khi ký hợp đồng: lớp kết nối giữa SignPass, EthSign, và TokenTable do ai xây và ai maintain? Nếu câu trả lời là "bạn tự làm," đó là thông tin quan trọng cần biết trước, không phải sau.
Đó cũng là lý do mình theo dõi Sign không qua số lượng sản phẩm trong ecosystem mà qua mức độ họ address perceived composability gap trong các deployment thực tế.
S.I.G.N. là một blueprint. Ai build sovereign infrastructure từ blueprint đó cần biết rõ phần nào đã được build sẵn và phần nào họ phải tự làm.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Mình bắt đầu đọc docs để tìm integration path.
Không có.
Không phải integration bị ẩn hay phức tạp. Docs của Sign viết thẳng: "TokenTable and EthSign are standalone products that use the same core primitives and can be integrated into S.I.G.N. deployments when appropriate." Không phải subsystem. Không phải native integration. Standalone products có thể kết hợp khi cần, nhưng không tự động kết nối với nhau.
Đây là perceived composability gap: Sign marketing ba sản phẩm như một hệ sinh thái tích hợp thống nhất, nhưng ở tầng kiến trúc, chúng là ba sản phẩm riêng biệt dùng chung một số building blocks nền tảng.
Tại sao mình nghĩ điều này quan trọng?
Khi một chính phủ quyết định dùng S.I.G.N. cho sovereign infrastructure, họ đang mua một "sovereign system architecture" theo cách Sign mô tả. Nhưng thực tế đó là 3 sản phẩm riêng biệt và chính phủ phải tự chịu trách nhiệm kết nối chúng lại thành một hệ thống hoàn chỉnh.
Sự khác biệt đó không nhỏ. Với một startup, kết nối ba sản phẩm riêng là việc bình thường. Với một chính phủ đang build national digital infrastructure cho hàng triệu công dân, lớp kết nối đó là thứ quyết định liệu hệ thống có vận hành được ở quy mô thực tế hay không.
Mình không nói Sign đang lừa dối. Docs viết rõ, ai đọc kỹ đều thấy. Vấn đề là marketing và whitepaper đang tạo ra một ấn tượng khác với thực tế kiến trúc. "S.I.G.N. is sovereign-grade digital infrastructure" nghe như một platform tích hợp. Nhưng S.I.G.N. trong docs được định nghĩa là "a system-level blueprint", một bản thiết kế, không phải một sản phẩm tích hợp sẵn.
Blueprint và integrated platform là hai thứ khác nhau hoàn toàn khi bạn phải implement ở cấp độ quốc gia.
Đây không phải lỗi kỹ thuật. Đây là khoảng cách giữa narrative và architecture. TokenTable đã distribute hơn 4 tỷ USD token cho hơn 40 triệu địa chỉ, con số đó là thật và ấn tượng. EthSign có user base thật. Sign Protocol đang được triển khai ở Kyrgyzstan và Sierra Leone. Mỗi sản phẩm đứng vững một mình.
Nhưng perceived composability gap có nghĩa là bất kỳ team nào đang evaluate Sign với kỳ vọng rằng ba sản phẩm này sẽ hoạt động liền mạch như một platform sẽ phải tự xây lớp kết nối đó. Và lớp kết nối cho sovereign infrastructure không phải thứ có thể làm trong một sprint.
Ai đang cân nhắc dùng Sign cho sovereign deployment cần hỏi một câu trước khi ký hợp đồng: lớp kết nối giữa SignPass, EthSign, và TokenTable do ai xây và ai maintain? Nếu câu trả lời là "bạn tự làm," đó là thông tin quan trọng cần biết trước, không phải sau.
Đó cũng là lý do mình theo dõi Sign không qua số lượng sản phẩm trong ecosystem mà qua mức độ họ address perceived composability gap trong các deployment thực tế.
S.I.G.N. là một blueprint. Ai build sovereign infrastructure từ blueprint đó cần biết rõ phần nào đã được build sẵn và phần nào họ phải tự làm.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Vedeți traducerea
Sign tạo bằng chứng không thể xóa trong một thế giới bắt buộc phải xóa?
Mình từng tư vấn cho một startup ở Đức muốn dùng Sign Protocol để lưu attestation KYC — bản ghi xác minh danh tính được lưu trên blockchain. Câu hỏi đầu tiên của luật sư họ khiến mình dừng lại khá lâu: nếu người dùng yêu cầu xóa dữ liệu theo GDPR, Sign có thể đáp ứng không? Mình không có câu trả lời.
Năm 2014, Mario Costeja González thắng kiện Google tại Tòa án Công lý Châu Âu. Google buộc phải xóa thông tin về ông khỏi kết quả tìm kiếm. Kể từ đó, right to be forgotten trở thành luật thực thi ở EU. GDPR Article 17 mở rộng quyền này: bất kỳ ai cũng có thể yêu cầu xóa dữ liệu cá nhân nếu dữ liệu không còn cần thiết cho mục đích ban đầu.
Sign Protocol đang build một thứ trực tiếp đối lập với nguyên tắc đó. Không phải vì Sign thiếu suy nghĩ. Mà vì bất biến là tính năng cốt lõi của kiến trúc. Một attestation được ghi lên chain là không thể xóa. Đây chính xác là thứ khách hàng Sign trả tiền để có.
Vấn đề bắt đầu khi Sign ký hợp đồng với các tổ chức trong jurisdiction có GDPR. Họ đang build hạ tầng mà về mặt kỹ thuật không thể tuân thủ một yêu cầu pháp lý có thể xuất hiện bất cứ lúc nào.
Đây là "erasure immunity conflict". Hệ thống được thiết kế để không thể xóa đang hoạt động trong môi trường pháp lý bắt buộc phải xóa thông tin.
Sign có một số giải pháp kỹ thuật. ZK selective disclosure cho phép người dùng chứng minh một thuộc tính mà không lộ dữ liệu gốc. Nếu dữ liệu nhạy cảm chỉ ghi hash hoặc commitment thì về lý thuyết không có gì để xóa cả.
Nhưng vấn đề không nằm ở lý thuyết. Khi developer vô tình ghi trực tiếp dữ liệu cá nhân lên chain — điều này đã xảy ra, không phải giả thuyết — không ai có cơ chế xóa record đó. Sign không thể xóa. Developer không thể xóa. Người dùng bị ảnh hưởng vẫn có quyền yêu cầu xóa theo GDPR.
Ai chịu trách nhiệm pháp lý? Theo GDPR, data controller — tổ chức quyết định mục đích và cách xử lý dữ liệu — phải chịu trách nhiệm tuân thủ right to erasure. Nếu một startup dùng Sign lưu attestation chứa dữ liệu cá nhân của người dùng EU, startup đó là data controller. Nhưng họ đang dùng một hệ thống mà về cấu trúc không thể xóa dữ liệu.
Khi phải chọn giữa tuân thủ GDPR và giữ nguyên tính toàn vẹn blockchain, một trong hai phải thua.
Đây không phải lỗi của Sign. Đây là collision giữa hai hệ thống được thiết kế với giả định căn bản trái ngược nhau. Blockchain assume dữ liệu phải tồn tại mãi mãi để đáng tin, trong khi luật bảo vệ dữ liệu assume ngược lại: dữ liệu phải có thể xóa để hợp pháp. Sign đang build ở giao điểm đó mà chưa có câu trả lời công khai cho erasure immunity conflict này.
Điều này không ngăn Sign triển khai ở các jurisdiction không có GDPR. Kyrgyzstan, Sierra Leone, UAE đều nằm ngoài phạm vi áp dụng trực tiếp. Nhưng khi Sign mở rộng sang EU, hoặc khi các dự án build trên Sign phục vụ người dùng EU, erasure immunity conflict trở thành vấn đề pháp lý thật.
Ai build trên Sign cho EU users cần đảm bảo một điều trước khi có bất kỳ dispute nào: không ghi dữ liệu cá nhân trực tiếp on-chain, chỉ ghi hash hoặc commitment, và document rõ ràng trong kiến trúc hệ thống. Đây không phải best practice. Đây là điều kiện tối thiểu để không rơi vào erasure immunity conflict với tư cách data controller vi phạm GDPR.
Đó cũng là lý do mình theo dõi Sign không chỉ qua số lượng deployment, mà qua cách họ address erasure immunity conflict trong các jurisdiction có right to erasure.
Bất biến là tính năng. Cho đến khi luật yêu cầu nó không được là tính năng nữa.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Năm 2014, Mario Costeja González thắng kiện Google tại Tòa án Công lý Châu Âu. Google buộc phải xóa thông tin về ông khỏi kết quả tìm kiếm. Kể từ đó, right to be forgotten trở thành luật thực thi ở EU. GDPR Article 17 mở rộng quyền này: bất kỳ ai cũng có thể yêu cầu xóa dữ liệu cá nhân nếu dữ liệu không còn cần thiết cho mục đích ban đầu.
Sign Protocol đang build một thứ trực tiếp đối lập với nguyên tắc đó. Không phải vì Sign thiếu suy nghĩ. Mà vì bất biến là tính năng cốt lõi của kiến trúc. Một attestation được ghi lên chain là không thể xóa. Đây chính xác là thứ khách hàng Sign trả tiền để có.
Vấn đề bắt đầu khi Sign ký hợp đồng với các tổ chức trong jurisdiction có GDPR. Họ đang build hạ tầng mà về mặt kỹ thuật không thể tuân thủ một yêu cầu pháp lý có thể xuất hiện bất cứ lúc nào.
Đây là "erasure immunity conflict". Hệ thống được thiết kế để không thể xóa đang hoạt động trong môi trường pháp lý bắt buộc phải xóa thông tin.
Sign có một số giải pháp kỹ thuật. ZK selective disclosure cho phép người dùng chứng minh một thuộc tính mà không lộ dữ liệu gốc. Nếu dữ liệu nhạy cảm chỉ ghi hash hoặc commitment thì về lý thuyết không có gì để xóa cả.
Nhưng vấn đề không nằm ở lý thuyết. Khi developer vô tình ghi trực tiếp dữ liệu cá nhân lên chain — điều này đã xảy ra, không phải giả thuyết — không ai có cơ chế xóa record đó. Sign không thể xóa. Developer không thể xóa. Người dùng bị ảnh hưởng vẫn có quyền yêu cầu xóa theo GDPR.
Ai chịu trách nhiệm pháp lý? Theo GDPR, data controller — tổ chức quyết định mục đích và cách xử lý dữ liệu — phải chịu trách nhiệm tuân thủ right to erasure. Nếu một startup dùng Sign lưu attestation chứa dữ liệu cá nhân của người dùng EU, startup đó là data controller. Nhưng họ đang dùng một hệ thống mà về cấu trúc không thể xóa dữ liệu.
Khi phải chọn giữa tuân thủ GDPR và giữ nguyên tính toàn vẹn blockchain, một trong hai phải thua.
Đây không phải lỗi của Sign. Đây là collision giữa hai hệ thống được thiết kế với giả định căn bản trái ngược nhau. Blockchain assume dữ liệu phải tồn tại mãi mãi để đáng tin, trong khi luật bảo vệ dữ liệu assume ngược lại: dữ liệu phải có thể xóa để hợp pháp. Sign đang build ở giao điểm đó mà chưa có câu trả lời công khai cho erasure immunity conflict này.
Điều này không ngăn Sign triển khai ở các jurisdiction không có GDPR. Kyrgyzstan, Sierra Leone, UAE đều nằm ngoài phạm vi áp dụng trực tiếp. Nhưng khi Sign mở rộng sang EU, hoặc khi các dự án build trên Sign phục vụ người dùng EU, erasure immunity conflict trở thành vấn đề pháp lý thật.
Ai build trên Sign cho EU users cần đảm bảo một điều trước khi có bất kỳ dispute nào: không ghi dữ liệu cá nhân trực tiếp on-chain, chỉ ghi hash hoặc commitment, và document rõ ràng trong kiến trúc hệ thống. Đây không phải best practice. Đây là điều kiện tối thiểu để không rơi vào erasure immunity conflict với tư cách data controller vi phạm GDPR.
Đó cũng là lý do mình theo dõi Sign không chỉ qua số lượng deployment, mà qua cách họ address erasure immunity conflict trong các jurisdiction có right to erasure.
Bất biến là tính năng. Cho đến khi luật yêu cầu nó không được là tính năng nữa.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Vedeți traducerea
Early this year, I used Sign Protocol to build a credential system for an edtech startup. Students who completed a course received an on-chain credential. Employers could verify it without seeing raw grade data. Test environment ran clean.
Production told a different story.
Students would get the completion email, claim their credential on Sign, and hit “attestation not found.” Reload a few times — it shows up. Employers would verify immediately, get an invalid result, then five minutes later it resolves. Support tickets piled up in week one.
Not a bug. Not a code issue.
This is Sign’s indexer lag window: the gap between when an on-chain record exists and when the off-chain indexer catches up. Sign uses an off-chain anchor architecture, with SignScan bridging the two.
During that gap, the chain says the credential exists. The API says it doesn’t.
Two conflicting truths at the same time.
That’s where my mental model broke.
This isn’t a design flaw. It’s a structural constraint. Sign doesn’t eliminate the data consistency problem. It relocates it — from on-chain to the gap between the indexer and the chain.
Last week Sign reported a 40% reduction in API latency after optimizing SignScan. Real improvement. But latency reduction doesn’t remove the lag window. It compresses it.
My fix: a polling layer on the client side, querying every 2 seconds until the attestation appears, capped at 30 seconds.
This works for delay-tolerant flows like certifications. It breaks in systems that assume instant finality — payments or access control.
At that point, the lag window isn’t UX. It’s a system constraint.
That’s why I track Sign by how they handle this gap over time.
Sign doesn’t eliminate the consistency problem.
It turns verification into a time-dependent function — where the same credential can be invalid, then valid, without anything changing on-chain.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Production told a different story.
Students would get the completion email, claim their credential on Sign, and hit “attestation not found.” Reload a few times — it shows up. Employers would verify immediately, get an invalid result, then five minutes later it resolves. Support tickets piled up in week one.
Not a bug. Not a code issue.
This is Sign’s indexer lag window: the gap between when an on-chain record exists and when the off-chain indexer catches up. Sign uses an off-chain anchor architecture, with SignScan bridging the two.
During that gap, the chain says the credential exists. The API says it doesn’t.
Two conflicting truths at the same time.
That’s where my mental model broke.
This isn’t a design flaw. It’s a structural constraint. Sign doesn’t eliminate the data consistency problem. It relocates it — from on-chain to the gap between the indexer and the chain.
Last week Sign reported a 40% reduction in API latency after optimizing SignScan. Real improvement. But latency reduction doesn’t remove the lag window. It compresses it.
My fix: a polling layer on the client side, querying every 2 seconds until the attestation appears, capped at 30 seconds.
This works for delay-tolerant flows like certifications. It breaks in systems that assume instant finality — payments or access control.
At that point, the lag window isn’t UX. It’s a system constraint.
That’s why I track Sign by how they handle this gap over time.
Sign doesn’t eliminate the consistency problem.
It turns verification into a time-dependent function — where the same credential can be invalid, then valid, without anything changing on-chain.
@SignOfficial $SIGN #SignDigitalSovereignInfra
SIGN
Deținere
PNL cumulat
+0.08%
Vedeți traducerea
Sign Protocol does not record national truth. It records what governments declare as national truth. This is what I call sovereign claim permanence: the claim is immutable, but its correctness is not.
It sounds similar, but the difference is crucial. Attestations are claims, not facts. When a citizen in Sierra Leone receives a digital identity through Sign, the chain logs that the government of Sierra Leone has verified their existence and eligibility. Nothing on-chain checks whether that claim matches reality. The chain only sees that a trusted issuer signed it.
This is not a flaw in Sign. It is a structural limit of attestation technology. Solving it would require the chain to judge authorities itself, and a chain that judges its authorities ceases to be neutral infrastructure.
The real issue emerges when authorities are states, and "claim" and "fact" begin to be used interchangeably in legal contexts. Kyrgyzstan is building Digital Som on Sign. Sierra Leone is putting its national ID on-chain. At this scale, a sovereign claim permanently recorded on blockchain is not just data. It carries legal weight.
I have not found any mechanism in Sign's docs for a citizen to challenge a false attestation about themselves. If one exists, I want to see it.
That is why I continue to watch how Sign handles dispute and revocation in national-level contracts. Not because I doubt the project, but because the answer to that question determines whether sovereign claim permanence becomes a feature or a liability.
It is not a question of technology. It is a question of who controls the definition of legal truth on-chain.
@SignOfficial $SIGN #SignDigitalSovereignInfra
It sounds similar, but the difference is crucial. Attestations are claims, not facts. When a citizen in Sierra Leone receives a digital identity through Sign, the chain logs that the government of Sierra Leone has verified their existence and eligibility. Nothing on-chain checks whether that claim matches reality. The chain only sees that a trusted issuer signed it.
This is not a flaw in Sign. It is a structural limit of attestation technology. Solving it would require the chain to judge authorities itself, and a chain that judges its authorities ceases to be neutral infrastructure.
The real issue emerges when authorities are states, and "claim" and "fact" begin to be used interchangeably in legal contexts. Kyrgyzstan is building Digital Som on Sign. Sierra Leone is putting its national ID on-chain. At this scale, a sovereign claim permanently recorded on blockchain is not just data. It carries legal weight.
I have not found any mechanism in Sign's docs for a citizen to challenge a false attestation about themselves. If one exists, I want to see it.
That is why I continue to watch how Sign handles dispute and revocation in national-level contracts. Not because I doubt the project, but because the answer to that question determines whether sovereign claim permanence becomes a feature or a liability.
It is not a question of technology. It is a question of who controls the definition of legal truth on-chain.
@SignOfficial $SIGN #SignDigitalSovereignInfra
C
SIGN/USDT
Preț
0,0324
Vedeți traducerea
Sign có Attestation bất biến. Authority thì không.
Sign Protocol đang xây hạ tầng danh tính quốc gia cho Kyrgyzstan và Sierra Leone. Attestation on-chain, immutable, không phụ thuộc vào server chính phủ có thể bị tắt hay bị hack. Trong bối cảnh ngày càng nhiều quốc gia thử nghiệm identity infrastructure và CBDC, cách thiết kế này không còn là lý thuyết. Nó đang dần trở thành hạ tầng thật.
Mình đọc whitepaper và thấy thiết kế đúng. Động cơ đúng. Nhưng có một câu hỏi mà docs không trả lời thẳng: điểm yếu của hệ thống này không nằm ở code. Nó nằm ở con người ký vào code.
Năm 2011, DigiNotar, một Certificate Authority của Hà Lan, bị hack. Hơn 500 SSL certificate giả được cấp. Về mặt kỹ thuật, không có gì sai. Các certificate này được ký hợp lệ bởi một authority hợp lệ. Vấn đề không nằm ở certificate. Nó nằm ở authority đứng sau certificate đó.
Sign Protocol được thiết kế để giải quyết lớp vấn đề này ở quy mô quốc gia. Và mình thật sự nghĩ đây là một trong số ít dự án crypto đang chạm vào thứ có tầm quan trọng thực sự với hàng tỷ người.
Nhưng đây là chỗ mình bắt đầu thấy có gì đó chưa ổn.
Sign không xóa bỏ authority. Nó chỉ làm cho kết quả của authority trở nên bất biến hơn. Trước khi một attestation tồn tại trên chain, phải có một trusted issuer quyết định cấp nó. Và trong mô hình sovereign infrastructure mà Sign đang triển khai, trusted issuer đó chính là chính phủ.
Đây không phải lỗi thiết kế. Đây là điểm yếu cấu trúc mà bất kỳ hệ thống danh tính nào cũng phải đối mặt. Sign chỉ đưa nó lên blockchain, nơi hệ quả của nó trở nên khó đảo ngược hơn.
Gọi đúng tên: đây là trusted issuer capture risk.
Mình không nói chính phủ Kyrgyzstan hay Sierra Leone có ý định xấu. Mình đang nói rằng một hệ thống đáng tin cậy phải được thiết kế để hoạt động đúng ngay cả khi authority hành xử sai. Sign Protocol, ở trạng thái hiện tại, chưa có câu trả lời công khai và rõ ràng cho câu hỏi đó.
Sierra Leone có 8 triệu dân. Nếu Sign là hạ tầng quốc gia và một quyết định chính trị khiến một nhóm dân số bị từ chối attestation, hoặc tệ hơn, bị cấp attestation sai, không có smart contract nào tự động phát hiện điều đó. Chain chỉ ghi nhận những gì issuer nói.
Đây không phải rủi ro kỹ thuật. Đây là rủi ro ai được phép định nghĩa sự thật.
Vấn đề này không mới. Hệ thống danh tính tập trung truyền thống thất bại vì authority bị mua chuộc, database bị rò rỉ, thẩm quyền cấp credential bị lạm dụng. Hệ thống trustless hoàn toàn ở đầu kia thất bại vì không ai chấp nhận credential nếu không có authority đứng sau bảo lãnh. Sign chọn con đường thứ ba: giữ authority nhưng làm bất biến kết quả của nó.
Bất biến không có nghĩa là đúng. Nó chỉ có nghĩa là không thể sửa.
Mô hình này hoạt động nếu authority không bao giờ bị compromise, không bao giờ bị chính trị hóa, không bao giờ hành xử ngược lại lợi ích của người được cấp credential. Nó thất bại chính xác trong những tình huống mà hệ thống danh tính quốc gia được cần đến nhất: khủng hoảng chính trị, chuyển giao quyền lực, tranh chấp về quyền công dân.
Sign đang xây sovereign infrastructure. Nhưng ở cấp độ đó, câu hỏi không còn là hệ thống có hoạt động hay không, mà là ai có quyền can thiệp khi hệ thống hoạt động sai.
Ai có quyền revoke một credential đã được cấp?
Ai có quyền tạm dừng một flow phân phối tiền?
Ai quyết định khi nào một attestation không còn hợp lệ?
Đó cũng là lý do mình tiếp tục theo dõi cách Sign thiết kế cơ chế dispute và revocation trong các hợp đồng cấp quốc gia. Vì ở cuối cùng, hệ thống này không loại bỏ vấn đề của authority, mà chỉ làm cho hậu quả của nó trở nên khó đảo ngược hơn.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Mình đọc whitepaper và thấy thiết kế đúng. Động cơ đúng. Nhưng có một câu hỏi mà docs không trả lời thẳng: điểm yếu của hệ thống này không nằm ở code. Nó nằm ở con người ký vào code.
Năm 2011, DigiNotar, một Certificate Authority của Hà Lan, bị hack. Hơn 500 SSL certificate giả được cấp. Về mặt kỹ thuật, không có gì sai. Các certificate này được ký hợp lệ bởi một authority hợp lệ. Vấn đề không nằm ở certificate. Nó nằm ở authority đứng sau certificate đó.
Sign Protocol được thiết kế để giải quyết lớp vấn đề này ở quy mô quốc gia. Và mình thật sự nghĩ đây là một trong số ít dự án crypto đang chạm vào thứ có tầm quan trọng thực sự với hàng tỷ người.
Nhưng đây là chỗ mình bắt đầu thấy có gì đó chưa ổn.
Sign không xóa bỏ authority. Nó chỉ làm cho kết quả của authority trở nên bất biến hơn. Trước khi một attestation tồn tại trên chain, phải có một trusted issuer quyết định cấp nó. Và trong mô hình sovereign infrastructure mà Sign đang triển khai, trusted issuer đó chính là chính phủ.
Đây không phải lỗi thiết kế. Đây là điểm yếu cấu trúc mà bất kỳ hệ thống danh tính nào cũng phải đối mặt. Sign chỉ đưa nó lên blockchain, nơi hệ quả của nó trở nên khó đảo ngược hơn.
Gọi đúng tên: đây là trusted issuer capture risk.
Mình không nói chính phủ Kyrgyzstan hay Sierra Leone có ý định xấu. Mình đang nói rằng một hệ thống đáng tin cậy phải được thiết kế để hoạt động đúng ngay cả khi authority hành xử sai. Sign Protocol, ở trạng thái hiện tại, chưa có câu trả lời công khai và rõ ràng cho câu hỏi đó.
Sierra Leone có 8 triệu dân. Nếu Sign là hạ tầng quốc gia và một quyết định chính trị khiến một nhóm dân số bị từ chối attestation, hoặc tệ hơn, bị cấp attestation sai, không có smart contract nào tự động phát hiện điều đó. Chain chỉ ghi nhận những gì issuer nói.
Đây không phải rủi ro kỹ thuật. Đây là rủi ro ai được phép định nghĩa sự thật.
Vấn đề này không mới. Hệ thống danh tính tập trung truyền thống thất bại vì authority bị mua chuộc, database bị rò rỉ, thẩm quyền cấp credential bị lạm dụng. Hệ thống trustless hoàn toàn ở đầu kia thất bại vì không ai chấp nhận credential nếu không có authority đứng sau bảo lãnh. Sign chọn con đường thứ ba: giữ authority nhưng làm bất biến kết quả của nó.
Bất biến không có nghĩa là đúng. Nó chỉ có nghĩa là không thể sửa.
Mô hình này hoạt động nếu authority không bao giờ bị compromise, không bao giờ bị chính trị hóa, không bao giờ hành xử ngược lại lợi ích của người được cấp credential. Nó thất bại chính xác trong những tình huống mà hệ thống danh tính quốc gia được cần đến nhất: khủng hoảng chính trị, chuyển giao quyền lực, tranh chấp về quyền công dân.
Sign đang xây sovereign infrastructure. Nhưng ở cấp độ đó, câu hỏi không còn là hệ thống có hoạt động hay không, mà là ai có quyền can thiệp khi hệ thống hoạt động sai.
Ai có quyền revoke một credential đã được cấp?
Ai có quyền tạm dừng một flow phân phối tiền?
Ai quyết định khi nào một attestation không còn hợp lệ?
Đó cũng là lý do mình tiếp tục theo dõi cách Sign thiết kế cơ chế dispute và revocation trong các hợp đồng cấp quốc gia. Vì ở cuối cùng, hệ thống này không loại bỏ vấn đề của authority, mà chỉ làm cho hậu quả của nó trở nên khó đảo ngược hơn.
@SignOfficial $SIGN #SignDigitalSovereignInfra
#17 🔥Finalizarea NIGHT GLOBAL LEADERBOARD
Competiția Creatorpad $NIGHT a luat sfârșit și eu am terminat pe locul #17.
Trebuie să spun sincer că în etapa finală am fost destul de epuizat când am urmărit KOL-urile. În special astăzi am obținut +60 de puncte dar totuși am coborât 1 rang, așa că toată lumea poate să își imagineze cât de acerbă este competiția în vârful clasamentului.
Oricum, mulțumesc tuturor prietenilor vizitatori pentru suportul acordat în ultima vreme, și nu uitați că competiția creatorpad Sign este încă în desfășurare, cei care nu au participat încă, să se apuce imediat!
#CreatorpadVN
Competiția Creatorpad $NIGHT a luat sfârșit și eu am terminat pe locul #17.
Trebuie să spun sincer că în etapa finală am fost destul de epuizat când am urmărit KOL-urile. În special astăzi am obținut +60 de puncte dar totuși am coborât 1 rang, așa că toată lumea poate să își imagineze cât de acerbă este competiția în vârful clasamentului.
Oricum, mulțumesc tuturor prietenilor vizitatori pentru suportul acordat în ultima vreme, și nu uitați că competiția creatorpad Sign este încă în desfășurare, cei care nu au participat încă, să se apuce imediat!
#CreatorpadVN
Vedeți traducerea
Vì sao Mỹ không build thứ mà Sign đang build?
Hầu hết các chương trình phúc lợi thất bại không phải vì thiếu tiền, mà vì hệ thống bị phân mảnh. Identity nằm một nơi, compliance một nơi, payment là hệ riêng, audit trail lại là hệ khác. Khoảng trống giữa các mảnh đó là nơi tiền thất thoát và dữ liệu không thể reconcile.
Theo mình nghĩ Sign đã giải đúng bài toán này. Kiến trúc của Sign gộp toàn bộ flow vào một lớp duy nhất: xác thực danh tính, phân phối tiền, và lưu trữ bằng chứng đều chạy qua attestation layer. TokenTable, một sản phẩm của Sign cho thấy cách tiếp cận này có thể hoạt động ở quy mô thực tế, hơn $130 triệu token đến 30 triệu user mà không cần reconcile nhiều hệ song song. Thiết kế này hoàn toàn hợp lý.
Rồi mình nghĩ đến DCash.
Năm 2022, CBDC (tiền số do ngân hàng trung ương phát hành) của Eastern Caribbean bị downtime gần hai tháng. Toàn bộ mạng lưới thanh toán số của tám quốc gia dừng lại vì một lỗi nâng cấp. Không phải một module, mà là toàn hệ thống, vì tất cả phụ thuộc vào một layer duy nhất. Điều này không xảy ra vì thiết kế kém, mà vì bất kỳ hệ thống tập trung nào cũng có một điểm như vậy. Sign đang build thứ còn phức tạp hơn thế.
Khi identity, compliance, payment và audit cùng chạy qua một layer trên Sign, single point of failure và single point of control hội tụ thành một. Một sự cố hoặc một quyết định có thể khiến một người vừa không xác thực được danh tính vừa không nhận được tiền. Đến đây mình bắt đầu thấy vấn đề không còn là kỹ thuật nữa.
Tháng 7 năm 2025, Hạ viện Mỹ thông qua Anti-CBDC Surveillance State Act, cấm Fed phát hành CBDC trực tiếp cho công chúng. Lý do chính thức là privacy và rủi ro "programmable money". Nhưng cách mình đọc là: Mỹ đang tránh xây một hệ thống nơi một layer duy nhất kiểm soát cả identity lẫn payment. Sign thì đang build chính thứ đó cho hơn 20 quốc gia khác.
Open standard không giải quyết được điều này. Audit được không có nghĩa là kiểm soát được. Câu hỏi thực sự là ai có quyền pause hệ thống, revoke credential, hay freeze account khi có lý do an ninh. Trong sovereign deployment, câu trả lời luôn là chính phủ. Và không phải hệ thống pháp quyền nào cũng giống nhau.
Sign không chỉ là hạ tầng. Nó là một lớp kiểm soát hợp nhất, nơi identity, money và policy hội tụ vào cùng một bề mặt vận hành.
Sign đã giải rất tốt bài toán minh bạch và chống tham nhũng. Nhưng mức độ an toàn của nó không nằm ở protocol, mà nằm ở thực thể vận hành layer đó.
Sign đang cung cấp một hạ tầng nơi quyền kiểm soát identity, payment và policy hội tụ vào cùng một điểm. Protocol có thể đảm bảo tính minh bạch của dữ liệu, nhưng không thể quyết định cách quyền lực đó được sử dụng.
DCash cho thấy chỉ cần một lỗi kỹ thuật cũng đủ làm tê liệt toàn bộ hệ thống. Nhưng với Sign, rủi ro không chỉ là hệ thống tự hỏng. Cùng một layer đó còn có thể bị tác động bởi quyết định từ phía vận hành. Một lệnh pause, một quyết định revoke credential, hay một lý do an ninh là đủ để một người vừa mất khả năng xác thực danh tính vừa không thể nhận hoặc sử dụng tiền cùng lúc.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Theo mình nghĩ Sign đã giải đúng bài toán này. Kiến trúc của Sign gộp toàn bộ flow vào một lớp duy nhất: xác thực danh tính, phân phối tiền, và lưu trữ bằng chứng đều chạy qua attestation layer. TokenTable, một sản phẩm của Sign cho thấy cách tiếp cận này có thể hoạt động ở quy mô thực tế, hơn $130 triệu token đến 30 triệu user mà không cần reconcile nhiều hệ song song. Thiết kế này hoàn toàn hợp lý.
Rồi mình nghĩ đến DCash.
Năm 2022, CBDC (tiền số do ngân hàng trung ương phát hành) của Eastern Caribbean bị downtime gần hai tháng. Toàn bộ mạng lưới thanh toán số của tám quốc gia dừng lại vì một lỗi nâng cấp. Không phải một module, mà là toàn hệ thống, vì tất cả phụ thuộc vào một layer duy nhất. Điều này không xảy ra vì thiết kế kém, mà vì bất kỳ hệ thống tập trung nào cũng có một điểm như vậy. Sign đang build thứ còn phức tạp hơn thế.
Khi identity, compliance, payment và audit cùng chạy qua một layer trên Sign, single point of failure và single point of control hội tụ thành một. Một sự cố hoặc một quyết định có thể khiến một người vừa không xác thực được danh tính vừa không nhận được tiền. Đến đây mình bắt đầu thấy vấn đề không còn là kỹ thuật nữa.
Tháng 7 năm 2025, Hạ viện Mỹ thông qua Anti-CBDC Surveillance State Act, cấm Fed phát hành CBDC trực tiếp cho công chúng. Lý do chính thức là privacy và rủi ro "programmable money". Nhưng cách mình đọc là: Mỹ đang tránh xây một hệ thống nơi một layer duy nhất kiểm soát cả identity lẫn payment. Sign thì đang build chính thứ đó cho hơn 20 quốc gia khác.
Open standard không giải quyết được điều này. Audit được không có nghĩa là kiểm soát được. Câu hỏi thực sự là ai có quyền pause hệ thống, revoke credential, hay freeze account khi có lý do an ninh. Trong sovereign deployment, câu trả lời luôn là chính phủ. Và không phải hệ thống pháp quyền nào cũng giống nhau.
Sign không chỉ là hạ tầng. Nó là một lớp kiểm soát hợp nhất, nơi identity, money và policy hội tụ vào cùng một bề mặt vận hành.
Sign đã giải rất tốt bài toán minh bạch và chống tham nhũng. Nhưng mức độ an toàn của nó không nằm ở protocol, mà nằm ở thực thể vận hành layer đó.
Sign đang cung cấp một hạ tầng nơi quyền kiểm soát identity, payment và policy hội tụ vào cùng một điểm. Protocol có thể đảm bảo tính minh bạch của dữ liệu, nhưng không thể quyết định cách quyền lực đó được sử dụng.
DCash cho thấy chỉ cần một lỗi kỹ thuật cũng đủ làm tê liệt toàn bộ hệ thống. Nhưng với Sign, rủi ro không chỉ là hệ thống tự hỏng. Cùng một layer đó còn có thể bị tác động bởi quyết định từ phía vận hành. Một lệnh pause, một quyết định revoke credential, hay một lý do an ninh là đủ để một người vừa mất khả năng xác thực danh tính vừa không thể nhận hoặc sử dụng tiền cùng lúc.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Vedeți traducerea
Sign Protocol lets anyone create a schema, the template that defines what an attestation looks like, without asking permission. No registration, no approval, no fees. The first time I read this in their docs, I genuinely thought this was the part that separated Sign from everything else. Open in a way that most protocols only claim to be.
Then I kept reading and something started to feel off.
Permissionless does not mean equal. Sign’s own documentation shows the number of schemas on the protocol grew exponentially throughout 2025, yet most never see real adoption. The problem is not creation, it is selection. Usage does not flow to the best design. It flows to whoever has enough leverage to set the standard.
When UAE selects a schema for its national ID system under S.I.G.N., every bank, every vendor, every app in that ecosystem follows. Not because that schema outperformed alternatives, but because it was chosen. Every developer who built a competing schema before that decision is now sitting on dead data, regardless of technical quality.
The more I think about it, the harder that is to ignore.
If anyone can create a schema but only a few can turn one into a standard, then what is being decentralized is not trust itself, but access to the competition for defining it. Sign does not remove power from the trust system. It formalizes it, turning trust into a standard-setting game where legitimacy comes from adoption, not design.
That shift matters. Power is no longer hidden inside private databases. It is moved onto a public layer where it becomes visible, enforceable, and still unevenly distributed. That is a very different promise from what permissionless tends to imply, and it is a gap the docs barely acknowledge.
So when Sign says anyone can participate in the global trust system, I read it less as an open invitation and more as a structural question: who actually has the leverage to make the rest of the world accept their definition of trust, and who is excluded from ever doing so?
@SignOfficial $SIGN #SignDigitalSovereignInfra
Then I kept reading and something started to feel off.
Permissionless does not mean equal. Sign’s own documentation shows the number of schemas on the protocol grew exponentially throughout 2025, yet most never see real adoption. The problem is not creation, it is selection. Usage does not flow to the best design. It flows to whoever has enough leverage to set the standard.
When UAE selects a schema for its national ID system under S.I.G.N., every bank, every vendor, every app in that ecosystem follows. Not because that schema outperformed alternatives, but because it was chosen. Every developer who built a competing schema before that decision is now sitting on dead data, regardless of technical quality.
The more I think about it, the harder that is to ignore.
If anyone can create a schema but only a few can turn one into a standard, then what is being decentralized is not trust itself, but access to the competition for defining it. Sign does not remove power from the trust system. It formalizes it, turning trust into a standard-setting game where legitimacy comes from adoption, not design.
That shift matters. Power is no longer hidden inside private databases. It is moved onto a public layer where it becomes visible, enforceable, and still unevenly distributed. That is a very different promise from what permissionless tends to imply, and it is a gap the docs barely acknowledge.
So when Sign says anyone can participate in the global trust system, I read it less as an open invitation and more as a structural question: who actually has the leverage to make the rest of the world accept their definition of trust, and who is excluded from ever doing so?
@SignOfficial $SIGN #SignDigitalSovereignInfra
C
SIGN/USDT
Preț
0,03279
Am crezut odată că blockchain rezolvă problema încrederii deoarece totul este înregistrat și nimeni nu poate modifica. După ce am citit documentele TokenTable, mi-am dat seama că m-am înșelat pe jumătate.
TokenTable este un produs al Sign folosit pentru a distribui tokenuri, airdrop-uri, vesting pentru proiectele crypto. Diferența este că după fiecare rundă de distribuție, sistemul salvează automat o înregistrare pe blockchain care detaliază: această distribuție a fost realizată conform unor reguli specifice, cine a primit cât, la ce moment. Această înregistrare nu poate fi modificată de nimeni, nici măcar de echipa proiectului sau de Sign însăși. Chiar și după cinci ani poate fi verificată din nou. Designul este foarte interesant, dar am observat că există unele probleme.
Sistemul Sign poate înregistra că distribuția a fost efectuată conform regulilor stabilite. Însă nimeni nu verifică dacă acele reguli sunt corecte înainte de a rula. Cele două sunt complet diferite. Dacă un dezvoltator scrie greșit formula de calcul alocării sau din greșeală exclude un grup de utilizatori din lista de eligibilitate, sistemul va funcționa în continuare normal și va înregistra întregul proces ca o dovadă perfectă. O dovadă perfectă a unei greșeli perfecte.
Arbitrum 2023 este exemplul la care mă gândesc cel mai des: 148,595 de adrese false au primit 253 de milioane ARB din cauza unor reguli de filtrare cu o breșă. Dacă Arbitrum ar folosi TokenTable, întregul proces ar fi salvat pe blockchain cu dovezi complete. Un audit trail perfect. Dar este un audit trail al unei distribuții greșite.
Sign răspunde la întrebarea "sistemul funcționează conform procesului?" Întrebarea "acele reguli sunt corecte?" nu poate fi răspunsă de nimeni din sistem.
Ce valoare are o dovadă imposibil de șters a unei decizii greșite, în afară de a demonstra că acea greșeală nu poate fi negată?
@SignOfficial $SIGN #SignDigitalSovereignInfra
TokenTable este un produs al Sign folosit pentru a distribui tokenuri, airdrop-uri, vesting pentru proiectele crypto. Diferența este că după fiecare rundă de distribuție, sistemul salvează automat o înregistrare pe blockchain care detaliază: această distribuție a fost realizată conform unor reguli specifice, cine a primit cât, la ce moment. Această înregistrare nu poate fi modificată de nimeni, nici măcar de echipa proiectului sau de Sign însăși. Chiar și după cinci ani poate fi verificată din nou. Designul este foarte interesant, dar am observat că există unele probleme.
Sistemul Sign poate înregistra că distribuția a fost efectuată conform regulilor stabilite. Însă nimeni nu verifică dacă acele reguli sunt corecte înainte de a rula. Cele două sunt complet diferite. Dacă un dezvoltator scrie greșit formula de calcul alocării sau din greșeală exclude un grup de utilizatori din lista de eligibilitate, sistemul va funcționa în continuare normal și va înregistra întregul proces ca o dovadă perfectă. O dovadă perfectă a unei greșeli perfecte.
Arbitrum 2023 este exemplul la care mă gândesc cel mai des: 148,595 de adrese false au primit 253 de milioane ARB din cauza unor reguli de filtrare cu o breșă. Dacă Arbitrum ar folosi TokenTable, întregul proces ar fi salvat pe blockchain cu dovezi complete. Un audit trail perfect. Dar este un audit trail al unei distribuții greșite.
Sign răspunde la întrebarea "sistemul funcționează conform procesului?" Întrebarea "acele reguli sunt corecte?" nu poate fi răspunsă de nimeni din sistem.
Ce valoare are o dovadă imposibil de șters a unei decizii greșite, în afară de a demonstra că acea greșeală nu poate fi negată?
@SignOfficial $SIGN #SignDigitalSovereignInfra
Tranzacții recente
1 tranzacții
SIGN/USDT
Sign construiește cel mai transparent sistem de distribuție a asistenței, dar cei care au cea mai mare nevoie de el nu pot beneficia?
Văd că Protocolul Sign abordează corect o problemă pe care programele de asistență guvernamentală au eșuat timp de decenii: dacă banii ajung în mâinile persoanelor potrivite, în conformitate cu ce condiții și cine poate verifica acest lucru. Sistemul de Capital Nou în S.I.G.N., adică infrastructura suverană pe care Sign o construiește pentru guvern, permite ca fiecare distribuție de asistență să fie ancorată pe blockchain cu toate informațiile: cine este beneficiarul, care sunt condițiile conform setului de reguli, suma de bani și momentul. Nimeni nu poate modifica după ce a fost înregistrat. Nu este nevoie să avem încredere în cuvintele oficialilor. După cinci ani, se poate interoga și verifica. Aceasta este o adevărată avansare comparativ cu modul în care programele G2P, adică distribuția de la guvern la persoană, funcționează în prezent.
Promisiunea fondatoare a Sign este simplă: verificarea ar trebui să fie portabilă. Întregul Sistem Nou de ID, construit pe Credite Verificabile W3C, DIDs W3C și scheme de atestare deschisă, a fost conceput astfel încât niciun furnizor unic să nu controleze cine are dreptul să verifice ce. Când am citit prima dată acest lucru în documentele lor, mi s-a părut mai puțin o prezentare de produs și mai mult un principiu demn de susținut.
Apoi am citit cum funcționează de fapt desfășurarea suverană și ceva s-a schimbat.
Când UAE sau Thailanda se angajează în schema de atestare a Sign pentru un sistem național de ID, fiecare bancă, fiecare furnizor, fiecare aplicație care dorește să interacționeze cu acel ecosistem trebuie să urmeze exact acea versiune a schemei. Nu pentru că standardul deschis al Sign este tehnic superior alternativelor. Ci pentru că guvernul l-a încorporat în infrastructura publică și a te retrage înseamnă a reconstrui de la zero. Estonia a făcut acest lucru cu X-Road în 2001, sursă deschisă, liber de fork, totuși 99% dintre serviciile publice rulează acum prin el și niciun furnizor nu intră pe această piață fără o integrare completă. Deschiderea nu a oprit blocarea. Angajamentul politic a făcut-o.
S.I.G.N. merge pe aceeași cale. Odată ce un guvern desfășoară și un întreg ecosistem național se construiește pe o versiune specifică a schemei, costurile de schimbare fac partea deschisă aproape irelevantă. Un competitor ar putea implementa exact aceleași standarde W3C și totuși să piardă, pur și simplu pentru că fiecare acreditiv, fiecare atestare, fiecare flux de identitate este deja conectat la infrastructura Sign.
Portabilitatea devine o caracteristică care trăiește în specificație, dar nu pe piață. Sign ajunge să fie, de facto, gardianul verificării suverane, fără a necesita vreodată o clauză de exclusivitate.
Întrebarea la care tot revin: dacă stratul de atestare al Sign ajunge în 20 de țări, înseamnă "standard deschis" încă ceea ce promit documentele lor când mandatul suveran a făcut deja alegerea pentru toată lumea?
@SignOfficial $SIGN #SignDigitalSovereignInfra
Apoi am citit cum funcționează de fapt desfășurarea suverană și ceva s-a schimbat.
Când UAE sau Thailanda se angajează în schema de atestare a Sign pentru un sistem național de ID, fiecare bancă, fiecare furnizor, fiecare aplicație care dorește să interacționeze cu acel ecosistem trebuie să urmeze exact acea versiune a schemei. Nu pentru că standardul deschis al Sign este tehnic superior alternativelor. Ci pentru că guvernul l-a încorporat în infrastructura publică și a te retrage înseamnă a reconstrui de la zero. Estonia a făcut acest lucru cu X-Road în 2001, sursă deschisă, liber de fork, totuși 99% dintre serviciile publice rulează acum prin el și niciun furnizor nu intră pe această piață fără o integrare completă. Deschiderea nu a oprit blocarea. Angajamentul politic a făcut-o.
S.I.G.N. merge pe aceeași cale. Odată ce un guvern desfășoară și un întreg ecosistem național se construiește pe o versiune specifică a schemei, costurile de schimbare fac partea deschisă aproape irelevantă. Un competitor ar putea implementa exact aceleași standarde W3C și totuși să piardă, pur și simplu pentru că fiecare acreditiv, fiecare atestare, fiecare flux de identitate este deja conectat la infrastructura Sign.
Portabilitatea devine o caracteristică care trăiește în specificație, dar nu pe piață. Sign ajunge să fie, de facto, gardianul verificării suverane, fără a necesita vreodată o clauză de exclusivitate.
Întrebarea la care tot revin: dacă stratul de atestare al Sign ajunge în 20 de țări, înseamnă "standard deschis" încă ceea ce promit documentele lor când mandatul suveran a făcut deja alegerea pentru toată lumea?
@SignOfficial $SIGN #SignDigitalSovereignInfra
SIGN
Deținere
PNL cumulat
+0.13%
Sign Creează Dovezi Imutabile. CBDC Poate Fi Rollback
Protocolul Sign este conceput pentru a rezolva o problemă foarte specifică: cum să facem ca o acțiune în sistemul digital să devină o dovadă de necontestat. Mecanismul de bază este atestarea, adică un registru cu semnătură digitală ancorat pe blockchain, imuabil, interogabil, verificabil de oricine fără a fi nevoie să aibă încredere în declarațiile emitentului. Aceasta este stratul de dovezi al S.I.G.N., stratul pe care se bazează întregul sistem monetar, de identitate și capital național al Sign pentru a funcționa.
Fair launch corect în filozofie. Dar filosofia nu plătește inginerii
Am urmărit Midnight încă de la început și acesta este unul dintre foarte puținele blockchain-uri lansate în 2026 care nu au strâns fonduri de la VC. Fără a16z, fără Paradigm, fără Multicoin. Token-ul a fost distribuit prin Glacier Drop pentru comunitatea Cardano, Bitcoin și alte șase ecosisteme, fără vânzare privată, fără alocare cu preț redus pentru investitori. Charles Hoskinson a donat 200 milioane USD pentru a finanța procesul de dezvoltare.
În ceea ce privește filosofia, cred că aceasta este decizia corectă. Fără VC, înseamnă fără cliff vesting, fără grupuri de investitori care să dețină token-uri ieftine în așteptarea vânzării către retail. Token-ul a fost distribuit pe scară largă încă din prima zi, fără a fi concentrat în mâinile unui grup mic. Acesta este motivul pentru care comunitatea crypto consideră că Midnight este unul dintre cele mai reale fair launch-uri din acest ciclu. Simt că acest lucru a stabilit o adevărată încredere în comunitate, nu o încredere umflată prin marketing.
În ceea ce privește filosofia, cred că aceasta este decizia corectă. Fără VC, înseamnă fără cliff vesting, fără grupuri de investitori care să dețină token-uri ieftine în așteptarea vânzării către retail. Token-ul a fost distribuit pe scară largă încă din prima zi, fără a fi concentrat în mâinile unui grup mic. Acesta este motivul pentru care comunitatea crypto consideră că Midnight este unul dintre cele mai reale fair launch-uri din acest ciclu. Simt că acest lucru a stabilit o adevărată încredere în comunitate, nu o încredere umflată prin marketing.
Midnight a fost conceput pentru ca datele tale să nu părăsească niciodată dispozitivul. Niciun server nu le păstrează. Niciun terț nu poate fi hack-uit pentru a le expune.
Aceasta este decizia corectă. Complet corectă din punct de vedere al intimității.
Dar aici este locul unde încep să gândesc diferit.
Dacă datele sunt doar pe dispozitivul utilizatorului, atunci când dispozitivul se defectează, se pierde sau se șterge, acele date dispar odată cu el. Nu există opțiune de recuperare din partea rețelei pentru că rețeaua nu știe că acele date există. Nu există suport pentru clienți care să poată fi contactat. Nu există server de backup pentru a restaura.
Pentru un caz de utilizare personal, aceasta este o riscuri pe care utilizatorul și-o asumă. Dar pentru o afacere care folosește Midnight pentru a stoca contracte, dosare de clienți sau date de operare, aceasta este o altă întrebare. Nicio afacere nu va accepta o infrastructură în care un laptop defect poate șterge date importante.
Midnight rezolvă această problemă prin backup criptat, utilizatorul își face singur backup-ul stării private și păstrează cheia. Dar "auto-gestionarea backup-ului" este ceva ce a îngreunat adoptarea criptografiei încă de la început.
Cel mai bun sistem de intimitate este sistemul în care nimeni nu intermediază păstrarea datelor tale. Cel mai durabil sistem este cel care poate fi recuperat în cazul unui incident.
Aceste două aspecte eu nu am reușit încă să găsesc un punct comun.
@MidnightNetwork $NIGHT #night
Aceasta este decizia corectă. Complet corectă din punct de vedere al intimității.
Dar aici este locul unde încep să gândesc diferit.
Dacă datele sunt doar pe dispozitivul utilizatorului, atunci când dispozitivul se defectează, se pierde sau se șterge, acele date dispar odată cu el. Nu există opțiune de recuperare din partea rețelei pentru că rețeaua nu știe că acele date există. Nu există suport pentru clienți care să poată fi contactat. Nu există server de backup pentru a restaura.
Pentru un caz de utilizare personal, aceasta este o riscuri pe care utilizatorul și-o asumă. Dar pentru o afacere care folosește Midnight pentru a stoca contracte, dosare de clienți sau date de operare, aceasta este o altă întrebare. Nicio afacere nu va accepta o infrastructură în care un laptop defect poate șterge date importante.
Midnight rezolvă această problemă prin backup criptat, utilizatorul își face singur backup-ul stării private și păstrează cheia. Dar "auto-gestionarea backup-ului" este ceva ce a îngreunat adoptarea criptografiei încă de la început.
Cel mai bun sistem de intimitate este sistemul în care nimeni nu intermediază păstrarea datelor tale. Cel mai durabil sistem este cel care poate fi recuperat în cazul unui incident.
Aceste două aspecte eu nu am reușit încă să găsesc un punct comun.
@MidnightNetwork $NIGHT #night
Tranzacții recente
6 tranzacții
NIGHT/USDT
Am citit Protocolul Sign cu o presupunere destul de simplă: autentificare o dată, reutilizare în multe locuri.
Stratul de atestare standardizează datele prin schema, astfel încât diferite sisteme să poată citi aceeași definiție. Combinat cu ZK, utilizatorul poate dovedi identitatea fără a expune datele originale.
Pentru piețele precum Sierra Leone, unde mulți oameni nu au conturi bancare, acest lucru nu este doar convenabil. Este o modalitate de a participa în sistemul financiar încă de la început.
TokenTable arată că acest model funcționează. Miliarde de dolari au fost distribuiți pe baza datelor care pot fi verificate, în loc de o listă statică.
Până aici, totul are sens.
Dar am început să observ o deviație când privesc dintr-o altă perspectivă.
Sign este un protocol deschis. În teorie, atestarea poate fi portabilă. O identitate poate fi utilizată în mai multe sisteme fără a fi nevoie să fie reconstruită de la zero.
Dar când un guvern adoptă Sign pentru infrastructura națională, logica începe să se schimbe.
Când băncile, serviciile publice și plățile se bazează toate pe același sistem de atestare, întrebarea nu mai este „este portabil sau nu”.
Ci este: portabil pentru a merge unde?
Încă poți pleca din punct de vedere tehnic. Dar pentru ca alte sisteme să accepte acele date, trebuie să reconstruiești întreaga rețea de încredere de la zero. Și asta este ceva ce nu poate fi realizat rapid.
Dependența nu apare atunci când alegi să folosești Sign. Ea apare atunci când destule părți îl folosesc.
Atunci, nu ești blocat de cod. Ești blocat de ecosistem.
Unul este standard deschis.
Unul este adoptarea la scară națională.
Aceste două lucruri nu se contrazic la început. Dar când scala devine suficient de mare, „deschis” nu mai înseamnă „a scăpa”.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Stratul de atestare standardizează datele prin schema, astfel încât diferite sisteme să poată citi aceeași definiție. Combinat cu ZK, utilizatorul poate dovedi identitatea fără a expune datele originale.
Pentru piețele precum Sierra Leone, unde mulți oameni nu au conturi bancare, acest lucru nu este doar convenabil. Este o modalitate de a participa în sistemul financiar încă de la început.
TokenTable arată că acest model funcționează. Miliarde de dolari au fost distribuiți pe baza datelor care pot fi verificate, în loc de o listă statică.
Până aici, totul are sens.
Dar am început să observ o deviație când privesc dintr-o altă perspectivă.
Sign este un protocol deschis. În teorie, atestarea poate fi portabilă. O identitate poate fi utilizată în mai multe sisteme fără a fi nevoie să fie reconstruită de la zero.
Dar când un guvern adoptă Sign pentru infrastructura națională, logica începe să se schimbe.
Când băncile, serviciile publice și plățile se bazează toate pe același sistem de atestare, întrebarea nu mai este „este portabil sau nu”.
Ci este: portabil pentru a merge unde?
Încă poți pleca din punct de vedere tehnic. Dar pentru ca alte sisteme să accepte acele date, trebuie să reconstruiești întreaga rețea de încredere de la zero. Și asta este ceva ce nu poate fi realizat rapid.
Dependența nu apare atunci când alegi să folosești Sign. Ea apare atunci când destule părți îl folosesc.
Atunci, nu ești blocat de cod. Ești blocat de ecosistem.
Unul este standard deschis.
Unul este adoptarea la scară națională.
Aceste două lucruri nu se contrazic la început. Dar când scala devine suficient de mare, „deschis” nu mai înseamnă „a scăpa”.
@SignOfficial $SIGN #SignDigitalSovereignInfra
Semnătura protejează datele. Dar protejează utilizatorul?
Protocolul de Semnătură face un lucru pe care sistemele de identificare digitală anterioare nu l-au putut face. Folosește dovada ZK și BBS+, adică operațiuni criptografice care permit dovedirea unei afirmații corecte fără a expune datele originale, utilizatorul poate dovedi că are vârsta de 18 ani fără a fi necesar să trimită data nașterii, poate dovedi că aparține unei regiuni fără a dezvălui adresa completă. Datele sensibile nu părăsesc dispozitivul. Nu există un server central care să fie spart sau să scape informații. Dacă ne uităm doar la nivelul criptografic, acesta este un design foarte curat.
Midnight tách bài toán phí giao dịch thành hai lớp. $NIGHT este un activ de gestionare. DUST este combustibilul pentru a efectua tranzacții pe @MidnightNetwork , generat automat din deținerea NIGHT pe o perioadă de timp, apoi ars după fiecare utilizare. Acest design este corect deoarece separă valoarea activelor de costurile operaționale, evitând creșterea bruscă a costurilor ca în cazul Ethereum în 2021.
Dar când am citit cu atenție, am observat o consecință pe care documentul de tokenomics nu o subliniază suficient.
DUST se generează liniar în funcție de cantitatea de $NIGHT deținută. Cine deține 100 NIGHT are DUST mai mult decât cine deține 1 NIGHT de exact 100 de ori. Nu există un mecanism de ajustare în funcție de cererea reală sau de contribuție.
Un startup care dorește să construiască o aplicație medicală cu câteva mii de tranzacții pe zi trebuie să dețină suficient NIGHT dinainte pentru a acumula DUST treptat, nu trebuie să cumpere astăzi pentru a utiliza imediat. Dacă nu au suficient, ei sunt restricționați în comparație cu organizațiile care au deținut milioane de NIGHT și au acumulat DUST dinainte. Opțiunea este de a cumpăra mai mult NIGHT de pe piață sau de a depinde de whale-uri pentru a obține DUST. Nu este un cost mare. Este o barieră a activelor combinată cu o barieră temporală.
Eu urmăresc Midnight destul de atent și apreciez designul tehnic al lor. Dar acesta este un punct la care nu am văzut pe nimeni să pună întrebarea: accesul la rețea este distribuit în funcție de activele deținute, nu în funcție de cerere sau contribuție. Acesta este exact modul în care funcționează sistemul financiar tradițional. Midnight rezolvă problema confidențialității. Dar la nivel economic, Midnight readuce accesul la cei care au avut deja active de la început.
Poate un astfel de sistem să extindă adoptarea de către cei care au cu adevărat nevoie, sau în cele din urmă va continua să prioritizeze pe cei care au avut deja active de la început?
#night
Dar când am citit cu atenție, am observat o consecință pe care documentul de tokenomics nu o subliniază suficient.
DUST se generează liniar în funcție de cantitatea de $NIGHT deținută. Cine deține 100 NIGHT are DUST mai mult decât cine deține 1 NIGHT de exact 100 de ori. Nu există un mecanism de ajustare în funcție de cererea reală sau de contribuție.
Un startup care dorește să construiască o aplicație medicală cu câteva mii de tranzacții pe zi trebuie să dețină suficient NIGHT dinainte pentru a acumula DUST treptat, nu trebuie să cumpere astăzi pentru a utiliza imediat. Dacă nu au suficient, ei sunt restricționați în comparație cu organizațiile care au deținut milioane de NIGHT și au acumulat DUST dinainte. Opțiunea este de a cumpăra mai mult NIGHT de pe piață sau de a depinde de whale-uri pentru a obține DUST. Nu este un cost mare. Este o barieră a activelor combinată cu o barieră temporală.
Eu urmăresc Midnight destul de atent și apreciez designul tehnic al lor. Dar acesta este un punct la care nu am văzut pe nimeni să pună întrebarea: accesul la rețea este distribuit în funcție de activele deținute, nu în funcție de cerere sau contribuție. Acesta este exact modul în care funcționează sistemul financiar tradițional. Midnight rezolvă problema confidențialității. Dar la nivel economic, Midnight readuce accesul la cei care au avut deja active de la început.
Poate un astfel de sistem să extindă adoptarea de către cei care au cu adevărat nevoie, sau în cele din urmă va continua să prioritizeze pe cei care au avut deja active de la început?
#night
Cât de descentralizat este Midnight dacă compilatorul rămâne centralizat?
Există un detaliu în arhitectura lui @MidnightNetwork pe care îl observ că puțini oameni îl aprofundează: întregul ecosistem de dezvoltare depinde de un singur limbaj de programare, Compact, iar acest limbaj a fost creat de o companie privată, Shielded Technologies.
Compilatorul Compact traduce codul în circuit ZK, adică structura matematică folosită pentru a crea dovezi de zero-knowledge, apoi în JavaScript pentru a rula în DApp. Toate contractele inteligente, toate regulile de divulgare selectivă, toată logica de procesare a stării private a Midnight trece prin acest toolchain.
Compilatorul Compact traduce codul în circuit ZK, adică structura matematică folosită pentru a crea dovezi de zero-knowledge, apoi în JavaScript pentru a rula în DApp. Toate contractele inteligente, toate regulile de divulgare selectivă, toată logica de procesare a stării private a Midnight trece prin acest toolchain.
Conectați-vă pentru a explora mai mult conținut