Xác nhận tính đúng đắn của các phản hồi từ canister như thế nào?
Windy
06/02/2022 12:22
0 
304 
Giải thích kỹ thuật về cách các phản hồi từ các hợp đồng thông minh (canisters) chạy trên Internet Computer có thể được chứng nhận là ĐÚNG!
Như một người dùng tương tác với chuỗi khối Internet Computer, làm thế nào bạn có thể tin tưởng vào các phản hồi mà bạn nhận được? Nói cách khác, làm thế nào bạn có thể xác nhận rằng bạn đang thực sự nói chuyện với Internet Computer?
Hãy bắt đầu với việc nó sẽ trông như thế nào trong một thế giới lý tưởng. Hãy tưởng tượng rằng bạn đang tương tác với một dịch vụ đang chạy hoàn toàn trong một môi trường đáng tin cậy (ví dụ: máy tính của riêng bạn hoặc mạng ở công ty của bạn). Với mục đích của bài đăng trên blog này, dịch vụ mà chúng tôi đang xem xét có thể là đại lý đặt vé xem một chương trình nào đó.
Vì vậy, bạn tương tác với dịch vụ đó và đặt vé cho một chương trình sắp tới. Miễn là dịch vụ và mạng lưới đáng tin cậy, đó là tất cả những gì bạn cần để yên tâm và tin tưởng rằng bạn đã thực sự đặt chỗ (ví dụ số ghế là 5A) cho buổi biểu diễn. Trong thực tế, bạn có thể đang nói chuyện với một dịch vụ qua Internet, đó là một nơi nguy hiểm với đầy rẫy các mối nguy độc hại.
Bây giờ có một vấn đề: Điều gì sẽ xảy ra nếu ai đó giữa bạn và dịch vụ mà bạn đang nói chuyện muốn thao túng yêu cầu của bạn và các phản hồi tương ứng? Họ có thể đưa ra phản hồi không chính xác, chẳng hạn như sai chỗ ngồi hoặc thông báo cho bạn rằng bạn đã không thực sự đặt vé trong khi thực sự bạn đã đặt vé. Ngược lại, họ có thể cho bạn biết rằng bạn đã mua vé trong khi thực sự bạn không mua. Đây là dạng tấn công MITM (Man-in-the-middle)
Đó chính xác là loại vấn đề đang được giải quyết ở đây. Trên Internet, giải pháp đã được biết đến và nó dựa trên mật mã khóa công khai. Mỗi dịch vụ có một khóa bí mật. Đây là phím màu xanh ở bên phải trong hình dưới đây. Và khi phản hồi yêu cầu của bạn, dịch vụ sẽ sử dụng khóa bí mật của nó để ký vào phản hồi đó. Chữ ký được thể hiện bằng dải ruy băng màu xanh trong hình.
Là người dùng, bạn biết khóa công khai tương ứng của dịch vụ. Sử dụng khóa công khai đó, bạn có thể xác minh chữ ký trên phản hồi. Bạn có thể kiểm tra xem phản hồi có thực sự đến từ dịch vụ đó hay không và biết rằng bạn thực sự đã đặt vé. Đây là trải nghiệm thông thường khi bạn sử dụng dịch vụ qua internet.
Khi nói đến Internet Computer, mọi thứ tương tự nhưng hơi khác một chút. Dịch vụ mà bạn đang tương tác không phải là một máy chủ dịch vụ đầy đủ của riêng nó với các khóa bí mật của riêng nó, mà chỉ là mã chạy trong các hợp đồng thông minh (Canisters), tức là, một ứng dụng chạy trên Internet Computer, và nó không tự làm ra mật mã. Thay vào đó, nó được thực thi bởi cái được gọi là mạng con (subnet), là một tập hợp các node cùng điều hành canister, trong ví dụ này, là cơ quan đặt vé.
Subnet nói chung có thể tạo ra một chữ ký, giống như cái mà chúng ta đã thấy trước đó. Mặc dù có nhiều node tạo nên subnet và một số trong số chúng có thể là độc hại, nó chỉ có thể tạo chữ ký nếu đa số các node đồng ý về những gì cần ký. Điều này có nghĩa là ngay cả khi có một số node độc hại, chúng vẫn không thể tạo chữ ký giả. Do đó, khi nhận được phản hồi có chữ ký từ Internet Computer với chữ ký hợp lệ từ subnet, người dùng sẽ biết rằng đây là phản hồi đã được đồng ý, ngay cả khi một số node là độc hại.
Những chữ ký này được gọi là chữ ký ngưỡng. Điều thú vị ở đây là những chữ ký này hơi tốn kém để tạo ra. Các node cần cộng tác và giao tiếp với nhau để tạo ra một trong những chữ ký ngưỡng này. Do đó, nó sẽ không mở rộng quy mô để ký từng phản hồi riêng lẻ khi có thể có vài nghìn yêu cầu mỗi giây. Để giải quyết vấn đề đó, các phản hồi sẽ không được ký riêng lẻ. Những gì mạng thực hiện là ghi lại tất cả các phản hồi trong một thứ sẽ được gọi, chỉ cho mục đích của bài đăng blog này, là một “tài liệu/bản ghi” của subnet liệt kê tất cả các phản hồi.
Như bạn có thể thấy ở đây, ở đâu đó trong số các phản hồi này, có lưu ý rằng khi Kim, người dùng của chúng tôi trong ví dụ này, yêu cầu dịch vụ đặt vé cho một buổi biểu diễn, đặt chỗ của Kim đã thành công và chỗ ngồi là 5A. Cũng có những phản hồi cho Larry và những người dùng khác. Điều có thể làm về mặt lý thuyết là toàn bộ “tài liệu” này, có chữ ký từ khóa chữ ký ngưỡng của subnet, có thể được lấy và chuyển đến người dùng. Người dùng có thể xác minh rằng phản hồi của họ có trong tài liệu đó. Điều này sẽ không lý tưởng vì tất cả các phản hồi đều được ghi lại trong tài liệu này, vì vậy nó sẽ rất lớn. Hơn nữa, Kim thực sự không có bất kỳ nhu cầu nào để nhìn thấy các phản hồi cho các yêu cầu của Larry đối với một dịch vụ hoàn toàn không liên quan.
Do vậy, điều có thể làm là “tài liệu” có thể được biên tập lại, loại bỏ những phần mà Kim không nên nhìn thấy, và chỉ những phần có liên quan đến Kim mới có thể được đưa vào. Chữ ký sẽ vẫn có giá trị. Điều này có nghĩa là Kim bây giờ có thể xem tài liệu này và xác minh rằng phản hồi cho yêu cầu của cô là cô đã nhận được vé cho ghế 5A và chữ ký đó là chính xác. Ẩn các thông tin phản hồi mà Kim không nên nhìn thấy, sẽ làm cho “tài liệu” nhỏ gọn hơn.
Hiệu ứng này về nguyên tắc tương tự như nén tài liệu hoặc nén hình ảnh. Vì vậy, theo cách này, Kim nhận được một phản hồi có kích thước hợp lý, chỉ truyền đạt cho Kim những gì Kim cần biết.
Nhưng có một điều cần được xem xét. Subnet đang được nói đến này được gọi là subnet 5, có nghĩa là có nhiều hơn một subnet. Thật vậy, Internet Computer là một chuỗi khối có khả năng mở rộng vô hạn với số lượng subnet không ngừng tăng lên. Trong hình trên, Kim biết khóa công khai tương ứng với subnet 5. Với rất nhiều subnet, sẽ không lý tưởng nếu tất cả người dùng cần tất cả các khóa công khai tương ứng với tất cả các subnet. Ý tưởng là Kim thực sự chỉ có một khóa công khai, và một khi Kim đã tin tưởng vào một khóa công khai này, thì đó sẽ là một lượng dữ liệu nhỏ, nhưng đủ để xác minh tất cả dữ liệu đến từ Internet Computer.
Cách thực hiện là dùng một khóa công khai của Internet Computer, được biểu thị bằng màu cam trong hình dưới đây, là khóa công khai của một subnet cụ thể, được gọi là subnet gốc (root subnet). Root subnet gần giống với các subnet khác, nó cũng có các node, một số node có thể độc hại, hầu hết trong số đó là trung thực. Điều phân biệt root subnet với các subnet khác đó là người dùng biết khóa công khai của nó.
Trong “tài liệu” của root subnet, có danh sách tất cả các subnet của Internet Computer. Và như bạn có thể thấy, nó liệt kê rằng có subnet 5 trên Internet Computer và nó có phím màu xanh lam.
Cùng với phản hồi cho người dùng, subnet có thể bao gồm một bản sao được biên dịch lại của “tài liệu” đó. Điều này được gọi là ủy quyền, vì nó đang ủy thác sự tin cậy từ root subnet cho subnet 5. Giờ đây, người dùng có thể xem trong bản ghi này và tìm ra khóa công khai của subnet mà người dùng đang nói chuyện (subnet 5) và người dùng sẽ tìm thấy chìa khóa màu xanh lam ở đó. Đó là cách giải quyết vấn đề người dùng không cần biết mọi khóa công khai của tất cả các subnet mà chỉ cần biết khóa công khai của một subnet duy nhất (root subnet).
Đó là cách subnet xác nhận các phản hồi thay mặt cho Internet Computer đối với những gì được gọi là các “cuộc gọi cập nhật” (lệnh update). Các cuộc gọi cập nhật là một yêu cầu từ người dùng đến Internet Computer, thông qua sự đồng thuận, được đưa vào các khối, v.v. Họ có thể thay đổi trạng thái của dịch vụ của canister, điều này tất nhiên rất quan trọng đối với việc đặt trước một buổi biểu diễn, bởi vì bạn muốn canister đặt chỗ ghi rằng buổi biểu diễn đã được đặt trước. Cuối cùng, bạn nhận được phản hồi và phản hồi được chứng nhận, nghĩa là người dùng có thể xác minh nội dung theo cách mà tôi vừa nêu.
Toàn bộ quá trình chứng nhận này diễn ra hoàn toàn minh bạch đối với mã ứng dụng trong canister và cả mã ứng dụng ở phía máy khách. Tuy nhiên, các cuộc gọi cập nhật diễn ra chậm vì chúng phải trải qua sự đồng thuận, v.v. và quá trình này mất khoảng hai giây hoặc lâu hơn.
Giảm thiểu độ trễ là lý do tại sao các “cuộc gọi truy vấn” (lệnh select) cũng được cung cấp. Các cuộc gọi truy vấn là các cuộc gọi đến các phương thức mà không làm thay đổi trạng thái của canister. Bởi vì chúng không thay đổi trạng thái, không cần phải đặt chúng theo thứ tự xác định hoặc thực thi chúng trên tất cả các node sau đó sẽ cần trạng thái mới. Một cuộc gọi truy vấn có thể được đáp ứng bởi một node duy nhất, thay vì toàn bộ subnet.
Điều này có nghĩa là các cuộc gọi truy vấn có thể rất nhanh – chỉ vài mili giây thay vì vài giây. Nhưng bạn có thể nhận thấy rằng bây giờ có một vấn đề. Tôi đã nói rằng toàn bộ subnet là đáng tin cậy và chỉ toàn bộ subnet mới có thể thực hiện được chữ ký màu xanh lam này, nhưng một node duy nhất trên subnet có thể là độc hại. Khi node đơn có thể độc hại đó phản hồi lệnh gọi truy vấn của bạn, làm thế nào để bạn biết rằng phản hồi là chính xác? Node đơn không thể ký phản hồi bằng khóa màu xanh lam vì các node đơn không thể ký một mình. Vậy làm thế nào bạn có thể thực hiện một cuộc gọi truy vấn mà vẫn nhận được phản hồi đã được xác thực từ Internet Computer?
Điều này có thể thực hiện được bằng cách sử dụng một tính năng được gọi là các biến được chứng nhận. Một yếu tố quan trọng là điều này đòi hỏi sự hợp tác từ người tạo canister. Để xác nhận các cuộc gọi cập nhật, mã canister và các nhà phát triển ứng dụng không phải làm bất cứ điều gì đặc biệt, nó chỉ hoạt động bên ngoài canister. Để bảo mật các cuộc gọi truy vấn này và sử dụng các biến đã được chứng nhận để bảo mật chúng, bây giờ yêu cầu sự hỗ trợ từ ngay bên trong canister.
Khi người dùng thực hiện đặt chỗ – lưu ý rằng chúng tôi hiện đang xem xét yêu cầu mà người dùng muốn đặt chỗ cho buổi biểu diễn – canister đang ghi ở một khu vực đặc biệt của trạng thái hệ thống mà Kim đã đặt chỗ ngồi 5A. Về cơ bản, nó đang nói với hệ thống, “Xin hãy nhớ cho tôi rằng Kim đã đặt chỗ ngồi 5A” và điều này hiện được lưu trữ tách biệt với trạng thái bình thường của canister. Trên thực tế, nó được viết vào cùng một tài liệu ghi lại tất cả các phản hồi đã thấy trước đó. Hãy nhớ rằng toàn bộ tài liệu được ký bởi subnet bằng cách sử dụng dải băng màu xanh lam.
Điều này giúp ích khi cuộc gọi truy vấn xảy ra. Giả sử một ngày sau, Kim đã quên số ghế của mình và muốn sử dụng một cuộc gọi truy vấn để hỏi người tạo canister xem ghế của cô ấy là gì? Một cuộc gọi truy vấn là một trường hợp sử dụng rất hay cho việc này bởi vì chỉ cần kiểm tra chỗ ngồi bạn đã đặt không yêu cầu một cuộc gọi cập nhật. Khi xử lý truy vấn, canister có thể yêu cầu hệ thống cung cấp một bản sao đã được biên dịch lại từ bản ghi của subnet với mọi thứ đã được biên tập lại ngoại trừ thông tin mà chính canister đã yêu cầu hệ thống ghi nhớ (tức là Kim có ghế 5A). Bây giờ canister có thể bao gồm cái được gọi là chứng chỉ (tức là tài liệu được biên tập lại) trong thư phản hồi với Kim.
Và bây giờ Kim thực sự có thể kiểm tra xem phản hồi từ cái canister (“Bạn có ghế 5A”) có đúng hay không. Tất nhiên, điều này có nghĩa là kiểm tra chữ ký, nhưng có mã hiện có cho điều đó. Đây là cơ chế tương tự như kiểm tra tính hợp lệ của phản hồi đối với lệnh gọi cập nhật. Kim cũng cần kiểm tra xem thông tin đó không quá cũ vì có thể kẻ tấn công đã cho Kim một phản hồi hợp lệ, nhưng nó chỉ hợp lệ một tuần trước và mọi thứ đã thay đổi. Vì vậy, có một số thứ mà người dùng (cụ thể là mã máy khách ở phía người dùng) sẽ phải kiểm tra, khi chúng đã được kiểm tra, người ta thấy rằng phản hồi là chính xác.
Một sự phức tạp nhỏ nảy sinh do những ràng buộc của việc giữ cho hệ thống đơn giản. Khi thiết kế một hệ thống như Internet Computer, luôn có sự đánh đổi. Hệ thống có phức tạp hơn một chút và việc sử dụng nó (tức là theo quan điểm canister) thuận tiện hơn hay nó chỉ cung cấp một số tính năng tối thiểu và đặt một số gánh nặng lên canister để hệ thống có thể được duy trì đơn giản, và do đó cũng an toàn và dễ quản lý?
Trong trường hợp này, chỉ có 32 byte dung lượng lưu trữ được phép sử dụng tính năng mà tôi vừa nêu. Bây giờ 32 byte có thể là đủ để nói rằng Kim đã đặt chỗ ngồi 5A, nhưng một khi có nhiều hơn một vài người đang đặt chỗ, thì 32 byte không còn đủ nữa, nhưng đây không phải là vấn đề cơ bản. Thủ thuật có thể được áp dụng để khắc phục vấn đề này khá giống với thủ thuật đã được áp dụng chỉ một vài trang trình bày trước đó khi chúng ta xem xét cách subnet có thể sử dụng một chữ ký cho nhiều phản hồi. Một lần nữa, một trong những tài liệu có thể biên dịch lại này đang được sử dụng. Vì vậy, những gì có thể được thực hiện ở đây là cái canister, khi Kim đặt chỗ cho chương trình, lưu trữ thông tin rằng Kim có ghế 5A trong tài liệu riêng của mình. Nó cũng có thông tin khác về những người khác đặt chỗ của họ trong chương trình. Sau đó, nó tính toán một hàm băm mật mã của tài liệu. Giờ đây, khi Kim hỏi dịch vụ về vị trí mà cô ấy có, dịch vụ có thể trả lời bằng tài liệu từ subnet, bao gồm thông tin chẳng hạn như hàm băm mật mã, sau đó trả lời bằng bản sao dữ liệu canister đã được biên dịch lại để xác minh rằng thông tin đó bạn có ghế 5A là thực sự chính xác. Như trước đây, sự ủy quyền nhỏ này là cần thiết, kết nối chữ ký màu xanh lam với chiếc chìa khóa màu cam mà Kim có.Với tất cả những điều này, có thể theo dõi chuỗi tin cậy từ phản hồi mà người dùng nhận được đối với khóa mà người dùng đã có. Người dùng có thể kiểm tra xem phản hồi này có được bao gồm trong bản sao tài liệu được biên tập lại từ canister và góc dưới bên trái hay không. Nó có thể tính toán lại hàm băm gốc hoặc hàm băm mật mã của tài liệu đó và kiểm tra xem nó có được đưa vào tài liệu được biên dịch lại từ subnet hay không. Nó có thể kiểm tra chữ ký màu xanh lam trên tài liệu đó và đảm bảo rằng chữ ký này thực sự được ký bằng khóa tương ứng cho subnet đó trong một ủy quyền, tức là tài liệu được biên dịch lại từ mạng gốc trở lên ở góc dưới bên phải. Tài liệu đó được ký bằng phím màu cam. Người dùng có thể kiểm tra chữ ký đối với khóa công khai mà người dùng có. Đó là cách hệ thống có thể quản lý để xác nhận các phản hồi được gửi,
Chúng ta hãy xem xét kỹ hơn một chút về các tài liệu này, với đặc tính thú vị là thông tin có thể được biên tập lại và chữ ký vẫn có thể được xác thực. Cơ chế đang được sử dụng ở đây là một công cụ mật mã nổi tiếng được gọi là cây Merkle. Để tránh nhầm lẫn, hãy lưu ý rằng thuật ngữ “redactable” trong bài đăng blog này là một phép loại suy. Nó không đề cập đến một chữ ký có thể biên dịch lại theo nghĩa kỹ thuật.
Đây thực sự chỉ là cấu trúc dữ liệu Merkle, và điều này không có gì mới. Tôi muốn giải thích ở cấp độ thấp hơn một chút về cách hoạt động của những cây Merkle này và cách chúng có thể được sử dụng ở đây. Loại tương tự ban đầu tôi sử dụng là một tài liệu, nhưng một loại tương tự khác hoạt động tốt hơn ở đây: hệ thống tệp trong ổ cứng của bạn, nơi bạn có các thư mục và danh sách tên. Bên trong các thư mục này, có nhiều thư mục hơn, cũng như các tệp chứa dữ liệu. Đây là mô hình khái niệm mà tôi muốn ghi nhớ khi nói về những cái cây này. Bây giờ chúng có hình dạng cây và subnet duy trì một trong những cái cây này. Đó là lý do tại sao nó được gọi là cây trạng thái, với tất cả các loại thông tin. Nó có phản hồi cho các yêu cầu từ người dùng.Nó cũng có dữ liệu được chứng nhận được xem xét khi các lệnh gọi truy vấn được chứng nhận và sau đó là một loạt thông tin khác, chẳng hạn như thời gian hiện tại và nhiều dữ liệu nội bộ cần thiết để giữ cho toàn bộ Internet Computer hoạt động, chẳng hạn như nhắn tin giữa các subnet (cross-subnet). Vì vậy, cây này bây giờ là hình cây. Và sau đó trong bức tranh này, tôi đã vẽ nó đang phát triển xuống dưới vì trong khoa học máy tính, cây cối phát triển xuống dưới vì một lý do kỳ lạ nào đó, và có những thứ ở góc này dành cho dữ liệu trong cây. Vì vậy, đó là nơi chứa dữ liệu được chứng nhận mà canister lưu trữ; ở góc trên cùng bên trái, có ghi thời gian cây này được tạo ra. Bây giờ chúng ta muốn xác định một băm mật mã xác định duy nhất toàn bộ cây, bao gồm tất cả dữ liệu, tất cả các bảng trên các node và hình dạng của nó.
Như một bước kỹ thuật nhỏ hướng tới điều đó, cây cần được tạo thành một cây nhị phân. Như bạn có thể thấy, cây đang phân nhánh nhiều lần và sẽ đẹp hơn nếu cây thực sự là cây nhị phân. Vì vậy, mỗi node đều có một hoặc hai node con, và bạn có thể dễ dàng thực hiện phân nhánh và thay thế nó bằng nhiều phân nhánh nhị phân, đó là những viên kim cương nhỏ trên các trang trình bày bây giờ để có được thuộc tính đó. Điều tiếp theo cần phải làm là xác định cách tính toán băm mật mã của cây đó và nó có thể được thực hiện theo phương pháp từ dưới lên. Đối với các lá có dữ liệu, chỉ cần sử dụng hàm băm của dữ liệu, chẳng hạn như SHA-256. Sau đó, có các nhãn này – ví dụ: dữ liệu được chứng nhận, ở phía dưới bên trái. Và ở đó, băm của cây con đó là băm của nhãn và băm của mọi thứ bên dưới.
Đối với các node nhị phân, một cái gì đó tương tự cũng được thực hiện. Băm của một trong những node nhị phân này là băm của cây con bên trái và bên phải. Bằng cách này, một quy tắc đã được xác định để xác định một hàm băm theo mọi cách từ dưới lên trên và có một hàm băm ở gốc. Bằng cách này, một số lượng nhỏ 32 byte bây giờ là đủ để xác định toàn bộ cây. Nếu băm đó được ký, thì chữ ký đó có thể được sử dụng để xác thực mọi thứ bên trong cây. Tiếp theo, redaction cần phải diễn ra. Giả sử nếu bạn muốn tiết lộ với Kim rằng dữ liệu được chứng nhận của canister abcde-fgh là CAFFEE. Và có lẽ chúng tôi cũng muốn chứng tỏ rằng thời điểm hiện tại là thời điểm mà chúng tôi có chúng.Sau đó có thể loại bỏ tất cả các cây con không liên quan đến hai phần thông tin này. Nhưng hàm băm của cây con đã bị loại bỏ, được biểu thị bằng các chú thích nhỏ màu cam ở trên, cũng phải được ghi nhớ. Tại sao điều đó phải được thực hiện? Chà, nếu bây giờ bạn cung cấp cây đã cắt tỉa cho người dùng, bao gồm tất cả các hàm băm cho tất cả những nơi mà một thứ gì đó đã được cắt tỉa, thì người dùng có thể giống như trước đây từ dưới lên trên tính toán lại tất cả các hàm băm cho các node riêng lẻ, và do đó cũng cho node gốc.
Sau đó, chữ ký màu xanh lam của mã băm gốc đó, mã băm của node gốc, có thể được lấy và người dùng có thể xác thực chữ ký. Và đó là cách người dùng có thể xác thực chữ ký và ký toàn bộ cây, mặc dù người dùng không có toàn bộ cây. Vì vậy, đây là những gì được sử dụng trong các subnet để có tài liệu này nơi thông tin có thể được biên tập lại, nhưng nó được sử dụng ở nhiều nơi hơn – ví dụ: root subnet cũng đang sử dụng cây trạng thái, nhưng nó có thông tin bổ sung về subnet nào tồn tại và khóa công khai là gì. Và sau đó, trong ví dụ về cơ quan đặt vé, nơi các cuộc gọi truy vấn được chứng nhận, bản thân canister có thể có một trong các cấu trúc Merkle này để bao gồm tất cả thông tin về các chỗ đã được đặt sau một hàm băm nhỏ mà sau đó nó có thể cắm vào hệ thống như dữ liệu được chứng nhận.Đó là tóm tắt về cách hoạt động của cây Merkle. Nó là một công cụ rất linh hoạt, và nó có thể được sử dụng để tạo ra hiệu quả tốt trong Internet Computer.
Cuối cùng, tôi muốn hướng dẫn bạn các bước mà bạn phải thực hiện với tư cách là nhà phát triển canister, hay đúng hơn là nhà phát triển ứng dụng, trên Internet Computer nếu bạn muốn nhận được lợi ích của dữ liệu được chứng nhận để bảo mật các cuộc gọi truy vấn của mình. Điều này cần một số trợ giúp từ canister và bạn sẽ phải thực hiện một số bước phát triển. Đầu tiên, bạn phải nghĩ về loại truy vấn bạn cần bảo mật và nghĩ về cấu trúc dữ liệu Merkleized phù hợp với điều đó. Tôi đã chỉ cho bạn cây và cây thực sự hữu ích cho mọi thứ tra cứu giá trị quan trọng hoặc tương tự như hệ thống files. Nếu bạn có thứ gì đó phức tạp hơn, trong đó một số dữ liệu cần được tổng hợp hoặc chọn lọc, có thể bạn cần thứ gì đó khác hơn thế. Nó thực sự phụ thuộc vào ứng dụng của bạn. Trong trường hợp đơn giản, một cái cây như thế sẽ hoạt động. Sau đó, bạn phải duy trì cây đó như một phần của trạng thái canister bình thường của bạn. Vì vậy, điều này đang chạy trong bộ nhớ chính của chương trình của bạn đang chạy trên Internet Computer và bất cứ khi nào có lệnh gọi cập nhật thay đổi một phần trạng thái cần được phản ánh ở đó, bạn phải cập nhật cấu trúc Merkle đó. Bạn phải tính toán lại hàm băm gốc xác định tất cả dữ liệu trong cấu trúc đó và ghi dữ liệu đó ra dưới dạng dữ liệu được chứng nhận trong canister của bạn vào hệ thống.Khi xử lý một phương thức truy vấn, bạn phải tính toán phản hồi đối với phương thức truy vấn, sau đó bạn phải xem xét cấu trúc Merkle in-canister của mình và sắp xếp lại mọi thứ bạn không cần. Về cơ bản, bạn tính toán những gì đôi khi được gọi là “nhân chứng” chứng minh rằng phản hồi mà bạn thực sự đang trong quá trình đưa ra được chứa trong hàm băm mà bạn đã lưu trữ trước đó. Bạn cũng phải yêu cầu hệ thống cung cấp cho bạn chứng chỉ đó, tài liệu được biên tập lại, cho thấy rằng hàm băm bạn đã viết trước đó trong lần gọi cập nhật cuối cùng là mã mà bạn mong đợi. Và sau đó bạn gửi cho người dùng phản hồi, phần được biên tập lại của cấu trúc Merkle in-canister của bạn và bằng chứng rằng hàm băm gốc là hàm băm gốc của cấu trúc dữ liệu của bạn.
Liên quan đến mã máy khách, bạn sẽ phải viết một máy khách dành riêng cho dịch vụ của mình, bởi vì bạn phải làm một số việc cụ thể của máy chủ. Trước tiên, bạn kiểm tra xem chứng chỉ hệ thống có chính xác không, nếu không, một node độc hại có thể cung cấp cho bạn một kết quả cũ và khiến bạn tin rằng điều gì đó là đúng bây giờ có thể đúng một tuần trước, nhưng không còn đúng nữa. Sau đó, bạn phải kiểm tra xem đây có thực sự là dữ liệu cho canister mà bạn đang giao tiếp hay không. Nếu không, kẻ tấn công có thể cài đặt một canister khác trên subnet đó có trạng thái tương tự, chẳng hạn như một đại lý đặt vé giả mạo có thông tin rằng bạn có ghế 7D thay vì ghế 5A và xây dựng phản hồi dựa trên đó.
Vì vậy, bạn phải kiểm tra xem đây có phải là cái canister mà bạn đang thực sự nói chuyện hay không. Sau đó, bạn nhìn vào cấu trúc dữ liệu dành riêng cho ứng dụng từ cây Merkle đã được biên tập lại mà bạn nhận được từ canister. Bạn tính toán lại hàm băm gốc của nó và so sánh nó với hàm băm trong dữ liệu hệ thống. Cuối cùng, bạn phải kiểm tra xem những gì trong dữ liệu dành riêng cho ứng dụng có khớp với các tham số và phản hồi truy vấn của bạn hay không và cả hai đều quan trọng. Bạn phải ghi nhớ các tham số của truy vấn và cả phản hồi. Khi bạn đã thực hiện tất cả các kiểm tra này như một phần của mã máy khách, thì bạn có thể tin tưởng phản hồi, mặc dù nó đến từ một node có thể không đáng tin cậy.
Đối với các cuộc gọi cập nhật, như đã lưu ý trước đó, bạn không phải lo lắng về bất kỳ điều gì trong số này. Vì vậy, nếu điều này quá phức tạp hoặc nếu có thể các truy vấn của bạn không phù hợp với định dạng được cấu trúc Merkle hỗ trợ, bạn vẫn có tùy chọn sử dụng lệnh gọi truy vấn và sống với các đảm bảo bảo mật giảm hoặc bạn có thể sử dụng mã cập nhật và phát trực tiếp với hiệu suất giảm nhẹ. Chúng tôi đang tìm cách làm cho các lệnh gọi truy vấn an toàn hơn để ngay cả trong trường hợp bạn không làm gì đặc biệt với tư cách là nhà phát triển, bạn sẽ nhận được thêm một số đảm bảo và một số biện pháp bảo vệ chống lại các node độc hại. Điều này hiện đang được thực hiện, vì vậy hãy theo dõi để biết thêm thông tin.
Cho đến lúc đó, nếu bạn muốn biết thêm về các chi tiết kỹ thuật của những gì tôi đã trình bày, bạn sẽ tìm thấy tất cả chúng trong Đặc điểm kỹ thuật giao diện Internet Computer trong phần “Cây trạng thái hệ thống”, “Chứng nhận” và “Dữ liệu được chứng nhận”.
Nếu bạn có bất kỳ câu hỏi nào khác, chúng tôi sẵn lòng trợ giúp bạn trên Diễn đàn nhà phát triển để hỗ trợ bạn xây dựng các ứng dụng sáng tạo trên Internet Computer.
