Y_Italy

Mình ngồi nghĩ khá lâu về một câu hỏi, kiểu không phải để viết cho hay mà là thật sự tò mò.
Nếu Sign không chỉ là một “kiến trúc hay ho” trên giấy, mà thực sự được deploy ở cấp quốc gia… thì thế giới sẽ trông như thế nào?
Nghe hơi to tát, nhưng càng đọc kỹ tài liệu thì mình càng thấy câu hỏi này không hề vô lý.
Điều đầu tiên mình nghĩ tới là cái “evidence layer” mà Sign đang build. Nếu nhiều quốc gia cùng chạy New ID, New Money, New Capital trên cùng một nền tảng attestation như Sign Protocol, thì tất cả hành động quan trọng đều tạo ra record có cấu trúc giống nhau. Một payment ở nước A, một credential ở nước B, hay một chương trình trợ cấp ở nước C… về mặt dữ liệu thì đều “nói cùng một ngôn ngữ”.
Nghe hơi abstract, nhưng implications của nó khá lớn. Hiện tại nếu muốn audit một chương trình quốc gia, gần như phải dựa vào báo cáo nội bộ hoặc audit sau nhiều tháng. Còn nếu mọi thứ đều là attestation, có thể query trực tiếp qua SignScan, thì việc kiểm chứng không còn là chuyện “tin” nữa mà là “verify được”.
Mình không chắc mọi người đánh giá đúng mức chỗ này chưa.
Một điểm nữa mình nghĩ khá nhiều là về $SIGN . Bình thường mấy token hạ tầng hay rơi vào kiểu phải có adoption thì mới có value, mà adoption lại phụ thuộc vào token. Nhưng với Sign thì nếu một quốc gia đã dùng schema và attestation của họ trong vài năm, thì gần như không thể migrate sang hệ khác mà không phá vỡ toàn bộ dữ liệu cũ.
Kiểu chi phí chuyển đổi không phải là tiền, mà là chính trị và vận hành. Và chính phủ thì không có chuyện “reset dữ liệu” đơn giản như project crypto.
Điểm này làm mình thấy dynamics của $SIGN hơi khác so với mấy infra token mình từng thấy.

Còn một hướng nữa mình thấy khá thú vị nhưng cũng hơi… nhạy cảm. Nếu nhiều quốc gia cùng dùng chuẩn như W3C VC, OIDC4VP trong hệ ID của Sign, thì về mặt kỹ thuật, việc verify identity xuyên biên giới là khả thi. Không cần build một global ID system, chỉ cần các hệ độc lập nhưng dùng cùng chuẩn.
Nhưng mình nghĩ chỗ này sẽ bị chặn ở layer chính trị nhiều hơn là công nghệ. Không phải không làm được, mà là có muốn làm hay không.
Và có một điều mình để ý là Sign không phải kiểu dự án “vẽ từ đầu”. EthSign đã từng chạy thật, TokenTable cũng đã dùng thật. Nên cái hệ attestation này không phải từ trên trời rơi xuống, mà là được build dần từ mấy use case nhỏ hơn.
Dù vậy, mình vẫn thấy khoảng cách giữa “có sản phẩm” và “được chính phủ deploy” là cực lớn. Đây không phải tích hợp SDK, mà là một quyết định hạ tầng nhiều năm, ảnh hưởng tới hàng triệu người.
Nên mình cũng không chắc timeline sẽ như thế nào, hay quốc gia nào sẽ là người đầu tiên dùng full stack của họ.
Nhưng nếu nhìn purely về kiến trúc, thì đây là một trong số ít dự án mình thấy đang cố trả lời một câu hỏi lớn hơn nhiều so với crypto thông thường. Không phải “làm nhanh hơn” hay “rẻ hơn”, mà là làm sao để hệ thống quốc gia có thể verify được chính nó.
Mình vẫn đang theo dõi thêm, vì nếu nó đi đúng hướng như họ thiết kế thì khá đáng để chú ý.
@SignOfficial $SIGN #SignDigitalSovereignInfra

Mình để ý một thứ khá lặp lại khi đọc về mấy hệ thống quốc gia, đặc biệt là mấy chương trình liên quan tới identity, payment với phân phối ngân sách.
Không phải là họ không có hạ tầng. Ngược lại, họ có rất nhiều. Nhưng mỗi thứ lại được build ở một thời điểm khác nhau, bởi một vendor khác nhau, dưới một ngân sách khác nhau. Thành ra nhìn tổng thể thì… nó không khớp với nhau.
Một hệ identity được build cách đây vài năm, xong đến lúc triển khai payment rail thì lại dùng vendor khác, rồi chương trình trợ cấp thì lại thêm một hệ riêng nữa. Mỗi cái đều chạy được, nhưng khi cần kết nối lại thì bắt đầu có vấn đề.
Mình nghĩ đây là cái mà Sign đang cố giải, nhưng không phải theo kiểu vá từng chỗ.
Đọc kỹ hơn về S.I.G.N. thì mình thấy họ không xem New ID, New Money, New Capital là 3 sản phẩm riêng. Cảm giác như họ coi đó là 3 phần của cùng một hệ, và cái nối chúng lại không phải API mà là một “evidence layer” chung, cụ thể là Sign Protocol.
Tức là thay vì hệ capital phải gọi API từ hệ identity để check eligibility, thì nó chỉ cần verify một attestation đã được issue sẵn theo schema chung. Cái này nghe hơi kỹ thuật, nhưng mình hiểu đơn giản là các system đang “nói cùng một ngôn ngữ” ngay từ đầu.
Và cái này làm mình nghĩ lại về vấn đề fragmentation.
Trước giờ mình cứ nghĩ là do tech chưa tốt nên các hệ không connect được. Nhưng đọc tới đây thì thấy có vẻ không phải vậy. Vấn đề là trust. Một agency không verify được dữ liệu của agency khác thì cách đơn giản nhất là… tự build lại từ đầu.

Nên việc trùng lặp system thực ra không phải do họ làm sai, mà là do không có một layer chung để cả hai bên đều tin được.
Sign đang cố biến cái trust đó thành thứ có thể verify bằng cryptography, thay vì phải tin vào từng tổ chức riêng lẻ. Nếu nhiều agency cùng dùng chung một trust registry, cùng issue attestation theo schema giống nhau, thì theoretically họ không cần build lại từ đầu nữa.
Nhưng đến đây thì mình lại thấy hơi chững lại một chút.
Vì phần khó nhất không còn là tech. Để nhiều agency trong cùng một chính phủ agree dùng chung schema, chung governance cho trust registry… cái đó nghe giống bài toán chính trị hơn là kỹ thuật.
Nên mình thấy kiến trúc này khá hợp lý, thậm chí là rất clean nếu nhìn trên giấy.
Nhưng mình cũng không chắc khi triển khai thật, họ sẽ dùng full stack như Sign thiết kế, hay chỉ pick một phần rồi integrate với hệ cũ.
Dù vậy, cái ý tưởng gom cả money, identity và capital vào cùng một evidence layer thì mình thấy khác biệt thật. Không phải kiểu build nhiều sản phẩm rồi nối lại, mà là build từ đầu để nó không bị tách ra.
Mình vẫn đang đọc thêm, vì cảm giác đây là một trong mấy hướng hiếm hoi đang cố giải đúng vấn đề gốc, chứ không chỉ làm tốt hơn một phần nhỏ.
Nếu làm được như họ thiết kế thì khá thú vị. Còn nếu không thì… lại quay về bài toán cũ thôi.
@SignOfficial $SIGN #SignDigitalSovereignInfra

Mình đọc phần New ID System của Sign và có một chi tiết ban đầu tưởng không quan trọng lắm: offline verification. Chỉ một dòng kiểu QR, NFC… dễ lướt qua.
Nhưng càng nghĩ lại càng thấy nó không hề “phụ”.
Vì hầu hết các cuộc nói chuyện về Web3 identity đều mặc định là online. Có internet, có smartphone, verify real-time. Nhưng thực tế nếu triển khai ở cấp quốc gia, đặc biệt ở các thị trường đang phát triển, thì assumption đó không đúng. Rất nhiều nơi kết nối không ổn định, hoặc đơn giản là không có.
Nếu một hệ thống identity bắt buộc phải online để verify, thì nó không thực sự là “national system”, mà chỉ là hệ thống cho những khu vực có hạ tầng tốt.
Cách Sign xử lý khá thực tế. Credential có thể được trình bày qua QR hoặc NFC, verifier check chữ ký ngay trên thiết bị, không cần gọi server. Tức là phần “proof” được verify local.
Phần khó hơn là revoke. Vì credential có thể hợp lệ lúc cấp nhưng sau đó bị thu hồi. Sign dùng Bitstring Status List, kiểu một danh sách nén mà verifier có thể tải về và cache. Khi check thì chỉ cần đọc đúng vị trí bit là biết còn valid hay không.

Tất nhiên sẽ có độ trễ. Nếu danh sách chưa được cập nhật thì có thể check sai. Nhưng họ chấp nhận trade-off này, thay vì bắt mọi thứ phải online. Mình thấy đây là một quyết định khá thực tế, không cố “perfect hóa” một thứ vốn dĩ không thể perfect.
Một điểm mình thấy thú vị nữa là họ cố align với các chuẩn như mobile driver license. Tức là không build một hệ tách biệt, mà có khả năng “sống chung” với những gì chính phủ đã triển khai.
Nhìn tổng thể thì offline không phải chỉ là feature. Nó giống một tín hiệu cho thấy họ đang nghĩ tới deployment thật, ở những nơi điều kiện không lý tưởng.
Và mình nghĩ đó là thứ không nhiều dự án để ý ngay từ đầu.
@SignOfficial $SIGN #SignDigitalSovereignInfra

$BTC lúc này đang cho một cảm giác khá dễ chịu nếu chỉ nhìn vào price action ngắn hạn. Cấu trúc gọn lại, nhịp hồi có lực, và những cú phản ứng trông “có kiểm soát” hơn so với giai đoạn giảm trước đó. Nhưng chính những phase như vậy lại thường là lúc thị trường bắt đầu dựng lên những cái bẫy tinh vi nhất.
Nếu zoom out một chút, thứ đang diễn ra không phải là điều gì mới.
Cấu trúc hiện tại khá giống một dạng bear flag — nơi giá sau một nhịp giảm mạnh bắt đầu hồi lại trong một channel dốc lên. Về mặt hình thức, nó trông rất “healthy”: higher low, biên độ thu hẹp, volatility giảm. Nhưng về bản chất, đây thường chỉ là một pha pause trong xu hướng giảm lớn hơn.
Điểm đáng chú ý là các nhịp hồi này thường đi kèm với narrative “đã tạo đáy”. Và chính narrative đó mới là thứ tạo thanh khoản cho bước tiếp theo của thị trường.
Trong downtrend, thị trường không giảm theo đường thẳng. Nó giảm theo dạng “kéo – nghỉ – kéo tiếp”. Những nhịp nghỉ (consolidation + hồi nhẹ) chính là nơi kỳ vọng được build lại. Khi đủ người tin rằng xu hướng đã đảo chiều, đó cũng là lúc thị trường có đủ liquidity để tiếp tục di chuyển theo hướng ngược lại.
Nhìn vào cấu trúc trong chart, mỗi lần BTC cố gắng break lên phía trên channel đều thiếu follow-through rõ ràng. Thay vào đó là các rejection nhanh — dấu hiệu cho thấy lực mua chưa đủ để chuyển đổi cấu trúc lớn hơn.
Kịch bản đáng lưu ý lúc này không phải là BTC có thể hồi lên bao xa, mà là phản ứng của giá khi chạm các vùng phía trên. Nếu các vùng này tiếp tục đóng vai trò là nơi phân phối (distribution), thì toàn bộ nhịp hồi hiện tại rất có thể chỉ là một phần của setup bearish lớn hơn.
Một chi tiết quan trọng khác là cách thị trường “vẽ lại kỳ vọng”. Khi giá bắt đầu ổn định hơn, trader dễ chuyển từ trạng thái phòng thủ sang tìm kiếm cơ hội. Nhưng trong bối cảnh xu hướng lớn chưa thay đổi, việc chuyển trạng thái quá sớm thường dẫn đến việc bị kẹt ở những vị trí không có edge.
Tháng tới nhiều khả năng vẫn sẽ là giai đoạn nhiều nhiễu: các cú bật ngắn hạn, sweep thanh khoản hai đầu, và những pha di chuyển đủ đẹp để khiến cả long lẫn short đều bị cuốn vào.
Ở thời điểm này, điều quan trọng không phải là bắt đúng đáy — mà là hiểu mình đang đứng ở đâu trong cấu trúc lớn.
Chart có thể trông đẹp hơn, nhưng điều đó không đồng nghĩa với việc thị trường đã an toàn hơn.

#BTCETFFeeRace #BitcoinPrices #BTC

Mình ngồi lần lại lịch sử của Sign mấy hôm nay, kiểu không phải đọc narrative cho vui mà cố hiểu xem nó thực sự evolve như thế nào. Vì từ một tool ký tài liệu trên Ethereum mà đi tới xây infra cho quốc gia nghe nó hơi… xa nhau.
EthSign là điểm bắt đầu. Một nền tảng ký tài liệu on-chain, đơn giản thôi. Nhưng cái insight gốc của nó lại không đơn giản như vậy. Khi một tài liệu được ký, nó tạo ra một record có thể verify: ai ký, ký cái gì, lúc nào. Và cái record đó được anchor lên chain.
Đọc tới Sign Protocol thì mình bắt đầu thấy mọi thứ nối lại. Vì thực ra e-signature chỉ là một dạng attestation. Một bên xác nhận một claim tại một thời điểm. EthSign làm điều đó cho document, còn Sign Protocol thì mở rộng ra cho mọi loại dữ liệu có cấu trúc.
Schema định nghĩa dữ liệu, attestation là record được ký, còn SignScan là nơi query lại tất cả. Tức là từ một use case rất cụ thể, họ build thành một primitive chung.
Cái mình thấy thú vị nhất là cách họ “đặt lại câu hỏi”. EthSign từng hỏi: làm sao để một agreement có thể verify mà không cần bên trung gian? Sign Protocol thì hỏi: nếu câu trả lời đó áp dụng cho mọi loại claim trong một hệ thống quốc gia thì sao?
Và từ đó mới ra S.I.G.N. Một credential, một payment, hay một policy change đều chỉ là “claim”. Nếu tất cả đều đi qua attestation layer thì chúng trở thành thứ có thể kiểm chứng lại, không phụ thuộc vào một bên giữ dữ liệu.
TokenTable cũng fit vào câu chuyện này theo cách mình không nghĩ tới lúc đầu. Ban đầu mình nghĩ nó chỉ là tool vesting token, nhưng thực ra nó là execution layer cho phân phối vốn. Khi gắn với identity và attestation thì nó có thể scale sang các chương trình cấp quốc gia.
Phần YZI Labs (trước là Binance Labs) cũng đáng để ý. Họ đầu tư từ thời Sign còn gần với EthSign, tức là đặt cược vào cái thesis từ rất sớm: attestation không chỉ dùng cho ký tài liệu, mà có thể trở thành một lớp hạ tầng lớn hơn nhiều.
Nhưng mình vẫn thấy có một khoảng cách khá lớn. Build product cho crypto user và build hệ thống cho government là hai thế giới khác nhau. Một bug trong EthSign thì phiền, nhưng một bug trong hệ thống identity quốc gia thì là vấn đề hoàn toàn khác.
Nên đoạn phía trước mới là test thật. Lúc đó thì history sẽ là lợi thế hay gánh nặng, mình nghĩ chưa ai trả lời được.
Nhưng ít nhất khi nhìn lại, cái evolution này không hề random. Nó khá logic, chỉ là phải “zoom out” đủ xa mới thấy được.
@SignOfficial $SIGN #SignDigitalSovereignInfra $NOM

Mình đọc khá nhiều về cách chính phủ phân phối tiền, và có một cảm giác hơi khó chịu là phần này thực ra chưa bao giờ “giải xong”. Tiền vẫn được chuyển, chương trình vẫn chạy, nhưng phía sau là rất nhiều bước thủ công, reconcile bằng tay, và những thứ đó hiếm khi được nói ra.
Đó là lúc mình đọc tới New Capital System của Sign và bắt đầu nhìn nó theo một góc khác. Không phải là RWA hay tokenization nữa, mà giống một lớp nằm giữa policy và payment. Kiểu như một “programmable budget layer”.
Cách họ mô tả xoay quanh ba thứ: identity-linked, schedule-based, và deterministic reconciliation. Nghe hơi khô, nhưng ghép lại thì thành một hệ thống mà mỗi khoản chi đều gắn với một identity đã verify, chạy theo schedule định sẵn, và cuối cùng có thể truy ngược về đúng budget line ban đầu.
Ví dụ đơn giản là một chương trình trợ cấp nông nghiệp. Mỗi người một điều kiện khác nhau, số tiền khác nhau, lịch nhận khác nhau. Trong hệ thống cũ thì phải có cả team ngồi xử lý, check chéo, rồi cuối cùng audit lại từ nhiều nguồn dữ liệu không đồng nhất.
Còn theo cách Sign build thì eligibility nằm ở credential của ID system, còn việc phân phối do TokenTable xử lý theo schedule. Mỗi lần giải ngân đều tạo attestation, gắn với rule, với identity, với thời điểm cụ thể. Tức là dữ liệu audit không phải dựng lại sau, mà được tạo ra ngay lúc thực thi.
Mình cũng phải admit là ban đầu mình nghĩ TokenTable chỉ là tool vesting token kiểu crypto. Nhưng đọc kỹ thì thấy nó được dùng như một engine phân phối quy mô lớn, chỉ là thay vì ví ẩn danh thì gắn với identity thật.
Phần compliance cũng khá thú vị. Không phải check ví một lần rồi thôi, mà check credential liên tục. Nếu eligibility thay đổi thì các khoản chi sau đó tự động bị chặn. Và lý do cũng được ghi lại luôn.
Nghe thì khá “đúng”, nhưng mình vẫn thấy khoảng cách lớn nằm ở triển khai thực tế. Việc align nhiều bộ ngành, thống nhất schema, vận hành chung một hệ… không hề đơn giản.
Nhưng nếu nhìn thuần về kiến trúc, thì đây là một trong số ít cách tiếp cận mình thấy cố gắng giải bài toán phân phối ngân sách một cách có hệ thống, chứ không chỉ xử lý phần transaction.
Mình vẫn đang theo dõi thêm, vì nếu cái “programmable budget layer” này chạy được ngoài đời, thì impact của nó có thể lớn hơn nhiều so với narrative tokenization mà mọi người hay nói.
@SignOfficial $SIGN #SignDigitalSovereignInfra $BNB $PLAY

Mình cứ quay lại câu hỏi này mấy ngày nay, và thật ra vẫn chưa có câu trả lời nào làm mình thấy “ổn” hoàn toàn.
Về mặt kỹ thuật thì khá rõ rồi. Trust registry là nơi lưu issuer nào được phép, public key của họ là gì, dùng schema nào, revoke ra sao. Nhưng cái mình quan tâm lại là lớp phía trên: trong một deployment thật, ai có quyền thêm hoặc gỡ một issuer? Quy trình diễn ra thế nào? Có kiểm soát chéo không?
Vì nếu nhìn vào cách Sign build ID system, thì toàn bộ “trust” đều đi qua cái registry này. Credential hợp lệ vì issuer hợp lệ. Issuer hợp lệ vì có trong registry. Và registry hợp lệ vì… ai đó kiểm soát nó đúng cách.
Chính cái “ai đó” này mới là điểm mình thấy khó.
Trong bối cảnh quốc gia, sẽ có nhiều bên cùng tham gia. Bộ y tế, bộ tài chính, cơ quan cấp phép, mỗi bên đều có lợi ích và quyền hạn khác nhau. Nếu tất cả cùng dùng một trust registry, thì governance gần như chắc chắn sẽ có xung đột. Ai được quyền deaccredit một issuer? Ai xử lý khi key bị lộ? Ai duyệt schema mới?
Sign docs có nhắc tới governance, nhưng không đi sâu vào việc “ai quyết định cuối cùng”. Lúc đầu mình nghĩ đây là thiếu sót, nhưng nghĩ lại thì có thể đây là chủ ý. Nếu protocol áp đặt một governance model cố định, thì rất khó phù hợp với từng quốc gia, vì mỗi nơi có cách vận hành khác nhau.
Tức là Sign đưa ra framework, còn governance là do deployer tự thiết kế. Nghe hợp lý, nhưng cũng đồng nghĩa là mức độ “trust” sẽ phụ thuộc rất nhiều vào cách mỗi nước triển khai. Cùng một hạ tầng, nhưng độ an toàn có thể khác nhau rất xa.

Có một chỗ mình thấy họ làm khá gọn là key rotation với DID. Key cũ vẫn được lưu trong lịch sử, nên credential cũ vẫn verify được theo context thời điểm phát hành. Cái này mình thấy sạch sẽ hơn mình nghĩ ban đầu.
Revocation cũng vậy, dùng Bitstring Status List thì revoke theo batch khá hiệu quả. Nếu một issuer bị loại khỏi registry, thì toàn bộ credential của họ gần như mất trust ngay lập tức mà không cần xử lý từng cái.
Nhưng tới phần dispute thì lại quay về câu chuyện ban đầu. Nếu một credential bị revoke sai thì sao? Protocol có thể chứng minh chuyện đó đã xảy ra, nhưng giải quyết tranh chấp lại nằm ngoài chain. Nó là vấn đề pháp lý, hành chính, và mỗi quốc gia sẽ xử lý khác nhau.
Nên cuối cùng mình thấy câu hỏi về trust registry không phải là vấn đề kỹ thuật khó nhất, mà là vấn đề hệ quả lớn nhất. Nếu payment rail lỗi thì còn sửa được. Nhưng nếu trust registry bị lỗi, hoặc tệ hơn là bị lạm dụng, thì ảnh hưởng sẽ sâu hơn nhiều.
Sign có vẻ đã đưa ra đủ công cụ để xây một hệ thống “đáng tin”. Nhưng việc nó có thực sự đáng tin hay không lại phụ thuộc vào cách người ta sử dụng nó.
Mình vẫn chưa có kết luận rõ ràng cho câu này. Có lẽ đây là kiểu vấn đề mà chỉ khi có deployment thật mới thấy rõ được.
@SignOfficial $SIGN #SignDigitalSovereignInfra

Mình để ý một pattern khá lạ khi đọc về các chương trình phân phối của chính phủ. Không phải front-end bị lỗi, mấy thứ đó thường được làm khá chỉnh chu. Payment layer cũng không phải vấn đề, tiền vẫn chạy, giao dịch vẫn settle. Nhưng sau vài tháng thì bắt đầu có vấn đề, và thường không ai nói quá lớn.
Câu hỏi luôn quay lại một chỗ rất khó chịu: tiền có đến đúng người không, đúng số không, theo đúng điều kiện không, và quan trọng nhất là có chứng minh được không.
Cái gap này thường nằm giữa ba hệ: identity để xác minh người nhận, payment để chuyển tiền, và reporting để audit. Mỗi cái thường do một bên khác nhau làm, data format khác nhau, cuối cùng phải reconcile thủ công. Và chính chỗ này làm hệ thống “gãy”, chứ không phải do code hay hạ tầng.
Đọc Sign thì mình thấy họ không coi audit là thứ build sau, mà là thứ phải có ngay từ đầu. Mỗi lần phân phối đều tạo ra một attestation, gắn luôn với credential xác minh eligibility. Tức là payment và identity không còn tách rời rồi mới ghép lại, mà được link ngay từ lúc tạo dữ liệu.

Điều này nghe đơn giản nhưng giải được khá nhiều vấn đề thực tế. Ví dụ duplicate payment, thường không phải do bug, mà do hai hệ không “nói chuyện” với nhau. Nếu credential là input bắt buộc cho mỗi lần disbursement, thì ít nhất logic đó được enforce ngay từ đầu.
Cái mình thấy thú vị hơn là họ gọi output là “evidence manifest”. Không phải log để parse lại, mà là dữ liệu được thiết kế sẵn để audit. Và có thể query trực tiếp qua SignScan theo schema, theo thời gian, theo người nhận. Điều này nếu làm đúng thì giúp auditor không cần mò transaction nữa.
Phần deterministic reconciliation cũng đáng chú ý. Mỗi khoản chi đều gắn với một ruleset, một version policy cụ thể, và được lưu lại. Tức là sau này khi policy thay đổi thì vẫn truy ngược được context ban đầu, không bị “rewrite lịch sử”.
Nhưng đọc tới đây thì mình vẫn thấy có vài chỗ cần theo dõi. Toàn bộ mô hình này giả định identity, capital và evidence layer được triển khai đồng bộ. Trong thực tế thì mỗi bộ ngành, mỗi vendor có thể làm một phần, và integration luôn là phần khó nhất.
Schema governance cũng là một dấu hỏi. Nếu schema thay đổi giữa chừng thì dữ liệu trước và sau không còn đồng nhất, audit sẽ phức tạp hơn nhiều.
Nói chung, cái “audit gap” này là vấn đề thật, và Sign là một trong số ít dự án mình thấy coi nó là trung tâm của thiết kế. Nhưng từ architecture hợp lý tới deployment chạy được ngoài đời vẫn là một khoảng cách không nhỏ.
Mình vẫn đang theo dõi thêm, vì nếu họ giải được đúng chỗ này thì impact sẽ lớn hơn nhiều so với mấy narrative tokenization thông thường.
@SignOfficial $SIGN #SignDigitalSovereignInfra