Biên tập viên | Carol

Biên tập viên | Carol

Một câu hỏi thường được đặt ra: "Làm thế nào để nhận ra quyền đọc dữ liệu trên chuỗi trong hợp đồng?"

Đằng sau yêu cầu như vậy là nhà phát triển muốn đưa một số dữ liệu vào chuỗi và để hợp đồng thông minh quản lý và tính toán dữ liệu đó để đạt được sự đồng thuận trong kinh doanh, nhưng anh ta không muốn dữ liệu được hiển thị công khai để tránh những người tham gia trái phép khác vào chuỗi từ việc đọc nó, dẫn đến thông tin Give way.

Ý tưởng triển khai trực quan nhất là viết một đoạn logic lọc trong mã hợp đồng, đánh giá rằng người gọi đáp ứng các điều kiện nhất định (chẳng hạn như nằm trong danh sách trắng) trước khi cho phép trả lại dữ liệu, nếu không thì từ chối dữ liệu đó.

Chúng tôi đặt ra một trường hợp: có một chuỗi liên minh điểm và những người tham gia trong chuỗi bao gồm Alice, Bob, Carl, Dave, v.v. và các thành viên gia đình của họ. Chúng tôi hy vọng rằng số dư điểm của mỗi người chỉ có thể được đặt hiển thị cho chính anh ấy và gia đình anh ấy, chứ không phải cho những người tham gia khác. .

Máy khách gửi yêu cầu đến một nút nhất định thông qua giao diện cấp ứng dụng của chuỗi khối, gọi phương thức get của hợp đồng thông minh để kiểm tra các điểm của Bob và hợp đồng thông minh viết logic kiểm soát quyền để từ chối truy cập trái phép.

Bởi vì logic hoạt động của hợp đồng thông minh trên mỗi nút là nhất quán, bất kể yêu cầu được gửi đến nút nào, kết quả đều giống nhau. Điều này có vẻ như là một ý tưởng tốt, nhưng nó thực sự là như vậy?

Đây là kết luận đầu tiên: đây là cách tiếp cận "giảm nhẹ, không phải là vĩnh viễn" và nó không đảm bảo rằng dữ liệu sẽ không bị rò rỉ.

Từ nay, chúng ta sẽ soi xét lại vụ án này với tư duy “đa trung, bất tín”.

Trước tiên hãy phân tích: dữ liệu được lưu trữ trên chuỗi như thế nào? Trong trường hợp nào nó sẽ bị rò rỉ?

Các nút mạng chuỗi khối được phân phối trong môi trường của những người tham gia khác nhau.Do đặc điểm nhất quán dữ liệu của chuỗi khối, mỗi nút giữ một bản sao dữ liệu hoàn chỉnh. Bất kể cơ sở dữ liệu là cơ sở dữ liệu kiểu tệp như LevelDB/RocksDB hay cơ sở dữ liệu quan hệ như Mysql, dữ liệu sẽ nằm trong phiên bản cơ sở dữ liệu của mỗi nút.

Điều đó có nghĩa là, số dư điểm của Bob được lưu trên đĩa cứng của tất cả các nút và được xem trong công cụ cơ sở dữ liệu MySQL, có dạng như sau:

Nếu có một người tham gia có một số kinh nghiệm về công nghệ chuỗi khối trên chuỗi (với xác suất nhỏ) đang bí mật che giấu "sự độc hại" (còn được gọi là người chơi Byzantine), anh ta có thể sử dụng các công cụ để mở cơ sở dữ liệu cục bộ và truy vấn trực tiếp số dư của Bob. Bằng cách này, logic điều khiển sử dụng các hợp đồng để ngăn rò rỉ dữ liệu sẽ bị bỏ qua hoàn toàn. Nó đơn giản mà.

Ngoài ra, dữ liệu blockchain không chỉ liên quan đến hợp đồng mà còn liên quan chặt chẽ đến hồ sơ giao dịch.

Khi gửi một giao dịch, các tham số giao dịch sẽ chứa một phần hoặc toàn bộ dữ liệu (ví dụ: Alice chuyển 100 cho Bob) và giao dịch sẽ được đóng gói thành một khối và cuối cùng được ghi vào cơ sở dữ liệu nút.

Các truy vấn về dữ liệu khối và giao dịch thường không được triển khai với logic hợp đồng, do đó, chỉ cần viết logic lọc trong hợp đồng không thể ngăn việc đọc những dữ liệu này. Người chơi Byzantine có thể duyệt qua dữ liệu khối trong cơ sở dữ liệu cục bộ, lấy chi tiết lịch sử giao dịch, phát lại luồng giao dịch từ đầu đến cuối và biết rằng số dư hiện tại của Bob là 300.

Từ quan điểm của toàn bộ ngăn xếp công nghệ, việc một người chơi Byzantine sử dụng các công cụ để truy cập dữ liệu cục bộ, duyệt qua các khối và giao dịch là chuyện nhỏ, thậm chí anh ta có thể sửa đổi mã của hệ thống chuỗi khối, từ các khía cạnh của giao diện mạng chuỗi khối, chương trình bộ nhớ và công cụ hợp đồng thông minh. Cắt, đánh hơi và chặn dữ liệu văn bản gốc từ các gói giao thức, khối, luồng giao dịch, ngữ cảnh hợp đồng, dữ liệu trạng thái, v.v. Ngay cả khi dữ liệu được mã hóa và chìa khóa nằm trong tay chủ sở hữu nút, anh ấy vẫn có thể mở khóa nó. .

Do đó, bắt đầu từ mã cơ bản của chuỗi khối để kiểm soát quyền đọc dữ liệu cũng là vô ích, suy cho cùng thì ai cũng có thể thay đổi mã nguồn mở, "kẻ xấu" ở Trung Quốc là bá đạo và khó đề phòng.

Tóm lại, blockchain nhấn mạnhVàVà"Tính nhất quán", miễn là dữ liệu văn bản gốc được phát trên chuỗi, có vô số cách để người khác lấy được dữ liệu đó. Cho dù đó là ở lớp hợp đồng hay mã cơ bản, hầu hết tất cả logic điều khiển đọc đều giống nhưgiấy cửa sổchọc và phá, nhưDòng MaginotCùng là vô dụng.

Thấy vậy, có thể ai đó sẽ hỏi: Nếu việc đọc dữ liệu là bất khả kháng như vậy thì quyền "ghi" trên blockchain có còn ý nghĩa không? Câu trả lời là: có.

Quay trở lại ví dụ về điểm, chúng ta đặt Alice làm quản trị viên điểm để cô ấy có thể bắt đầu giao dịch chuyển điểm, sau đó Bob chỉ nhận điểm từ Alice. Giao dịch chuyển điểm cần thông qua sự đồng thuận của toàn mạng lưới, tất cả các nút đồng thuận sẽ kiểm tra các quy tắc được ghi trong hợp đồng và từ chối ký nếu không đáp ứng yêu cầu, nếu giao dịch vượt quá thẩm quyền không thể thống nhất, dữ liệu sẽ không bị sửa đổi.

Tại thời điểm này, ngay cả khi có một số lượng nhỏ các nút Byzantine, cho dù các nút cục bộ có cứng đến đâu, chúng cũng không thể can thiệp vào dữ liệu của toàn bộ mạng.

"Viết" các giao dịch theo đuổi sự đồng thuận, do đó, khi khách hàng gửi một giao dịch (sendTransaction hoặc sendRawTransaction), giao dịch đó phải được ký điện tử và hệ thống chuỗi khối xác minh chữ ký để xác nhận tài khoản bên ngoài nào đã gửi giao dịch, giao dịch này có thể được xác minh nghiêm ngặt và truy tìm chính xác.

Hoạt động "Đọc" nhấn mạnh hơn vào việc chia sẻ, hoạt động đọc dữ liệu không thực sự trải qua quá trình đồng thuận, chỉ lướt qua dữ liệu trên nút của chính bạn. Thông thường, hệ thống chuỗi khối không cần điền nghiêm ngặt người gửi trong giao diện đọc (gọi), cũng không cần ký điện tử, do đó, việc đánh giá tài khoản bên ngoài trong phương thức đọc hợp đồng là không hợp lệ.

Dựa trên phân tích trên, có thể kết luận rằng việc triển khai kiểm soát đọc trên chuỗi không phải là vấn đề đơn giản.

Nếu logic điều khiển đọc không được xem xét đầy đủ, hiệu quả sẽ là: bạn đọc dữ liệu trên nút của chính mình để kiểm tra và xác minh, và giao diện có vẻ ổn. Bạn nghĩ rằng năm tháng yên lặng, nhưng bạn không biết rằng dữ liệu đã bị lật bởi một người chơi Byzantine Từ dưới lên trên.

Xem xét sự mất lòng tin trong sự hợp tác của nhiều bên và việc theo đuổi chia sẻ dữ liệu, công khai và minh bạch, nói chung, nếu đó là dữ liệu quan trọng và nhạy cảm không thể bị rò rỉ, thì nó phải được tải lên chuỗi một cách cẩn thận. Ước số chung" có thể được chia sẻ.

Trên thực tế, trạng thái của các giao dịch và số dư trong nhiều hệ thống blockchain được hiển thị trên toàn bộ mạng. Cái gọi là ẩn danh hoặc quyền riêng tư chỉ sử dụng các khóa và hệ thống địa chỉ công khai và riêng tư để thay thế các tài khoản văn bản gốc. Nó không phù hợp với các lĩnh vực như tài chính và các công việc của chính phủ nơi mô hình phức tạp và quyền riêng tư toàn diện được nhấn mạnh.

Vậy chúng ta có những phương pháp nào khác để kiểm soát đúng mức độ hiển thị của dữ liệu trong khi tính đến việc chia sẻ, tính minh bạch và tính mở?

Ý tưởng đầu tiên làKết hợp với quản trị ngoài chuỗi, để thống nhất về ranh giới trách nhiệm và quyền lợi. Tôi đã hoàn thành tốt công việc thiết kế và triển khai các quyền ở cấp độ hợp đồng và giao diện để đảm bảo rằng không có dữ liệu nào bị rò rỉ trong hệ thống kinh doanh của tôi và lớp ứng dụng chuỗi khối, giao diện hiển thị, báo cáo, nhật ký, cơ sở dữ liệu và các liên kết khác của tôi sẽ không được truy cập bởi những người không được ủy quyền, loại bỏ rủi ro nội bộ.

Còn node của người khác thì mình không quan tâm, đó là trách nhiệm của họ, ai làm rò rỉ và lạm dụng dữ liệu sẽ bị xử lý nghiêm (thực ra rất khó để có được bằng chứng). Logic kiểu này thực ra hơi “quét tuyết trước cửa từng nhà”, ở chế độ này dữ liệu nhạy cảm của mình vẫn không up được cho người khác.

Ý tưởng thứ hai làgiới thiệu mật mã. Dưới đây là một vài ví dụ.

Mã hóa bất đối xứng:Dữ liệu trên chuỗi được mã hóa bằng khóa chung của người nhận và chỉ người nhận mới có thể mở khóa bằng khóa riêng của mình.

Phong bì mật khẩu:Dữ liệu đường lên được mã hóa bằng một mật khẩu nhất định và mật khẩu này được cấp cho người nhận thông qua kênh ngoại tuyến và chỉ người nhận biết mật khẩu mới có thể giải mã được.

Mã hóa tài sản:Dữ liệu được mã hóa bằng thuật toán mã hóa thuộc tính và chỉ những người đáp ứng các thuộc tính được chỉ định (chẳng hạn như thuộc tính quản trị viên) mới có thể được giải mã. Việc xem xét các giải pháp này là chi phí tính toán, truyền tải và lưu trữ sẽ cao hơn, ngoài ra, dữ liệu được mã hóa không hỗ trợ tính toán văn bản gốc, điều này gây khó khăn cho việc triển khai logic hợp đồng kinh doanh phức tạp. Cũng cần lưu ý rằng ngay cả khi nó được mã hóa, về cơ bản tất cả thông tin của dữ liệu vẫn nằm trên chuỗi. Cùng với thời gian, sự phát triển của sức mạnh tính toán và thuật toán (chẳng hạn như mật mã lượng tử), có khả năng bị cưỡng bức hoặc bởi vì Nếu khóa bị rò rỉ/dễ bị đoán ra và dữ liệu trên chuỗi không thể rút được, sẽ có nguy cơ bị công bố ra toàn thế giới.

Ý tưởng thứ ba làChỉ bản tóm tắt được tải lên chuỗi, bản rõ dữ liệu hoàn toàn không có trên chuỗi.

Trên thực tế, vai trò của chuỗi khối không nhất thiết phải nắm bắt đầy đủ dữ liệu và thực hiện các quy tắc kinh doanh phức tạp, mà dựa vào độ tin cậy của nhiều nhân chứng để xác minh tính chính xác và toàn vẹn của dữ liệu, đồng thời đóng vai trò làm bằng chứng và truy xuất nguồn gốc .Ở giai đoạn này, nhiều hệ thống chuỗi khối chủ yếu dựa trên logic như vậy, có thể phục vụ một cách khách quan như một điểm tin cậy.

Nếu bạn cần dữ liệu văn bản gốc, thì hãy sử dụng thông tin địa chỉ trong bản tóm tắt để lấy dữ liệu từ hệ thống ngoài chuỗi, thực hiện kiểm soát quyền hạn chi tiết trong liên kết này và tiến hành xác minh lẫn nhau với bản tóm tắt trên chuỗi.

Tuy nhiên, vẫn còn một chút hài hòa rằng dữ liệu không nằm trên chuỗi.Làm thế nào một khái niệm sáng tạo như vậy về chuỗi khối và chức năng mạnh mẽ như vậy của hợp đồng thông minh có thể được sử dụng đầy đủ?

đó là vềĐiện toán riêng tưMột loạt vũ khí hạng nặng, bao gồm nhưng không giới hạn ở bằng chứng không kiến ​​thức, mã hóa đồng hình, điện toán đa bên an toàn và học tập liên kết, có thể thực hiện cộng, trừ, nhân, chia, phép toán logic, sắp xếp và phân tích thống kê có thể đạt được nhiều hơn nữa ảnh hưởng của "quầy lễ tân ẩn danh và lý lịch có thể kiểm toán", để đáp ứng các yêu cầu tuân thủ quy định. Đây là ý nghĩa cuối cùng của "có sẵn vô hình" trên blockchain.

Do giới hạn về không gian, các chi tiết về tính toán quyền riêng tư không được thảo luận ở đây. Bạn có thể tham khảo các giải pháp kịch bản nguồn mở liên quan đến bảo vệ quyền riêng tư của WeDPR, đặc biệt là một số tình huống, chẳng hạn như sổ cái bản mã có thể kiểm chứng chuỗi khối VCL, có thể được sử dụng để giải quyết vấn đề điểm nêu trên.Một số vấn đề riêng tư trong trường hợp.

Các giải pháp tình huống mã nguồn mở liên quan đến bảo vệ quyền riêng tư của WeDPR:

https://fintech.webank.com/wedpr/VCL

phần kếthttps://sandbox.webank.com/wedpr/confidentialpayment/#/start

phần kết

Ban đầu, tôi chỉ muốn nói về một vấn đề nhỏ như "làm thế nào để viết quyền đọc hợp đồng", nhưng nó đã trở thành một bài viết dài.

Trên thực tế, khi đối mặt với việc lập trình và phát triển chuỗi khối, bạn thực sự không thể nghĩ đến các vấn đề như viết phần mềm độc lập hoặc phần mềm cụm, mà hãy xem xét đầy đủ mối quan hệ hợp tác trong môi trường có sự tham gia của nhiều bên và không tin cậy, dựa trên triết lý chia sẻ cơ bản , minh bạch và truy xuất nguồn gốc. Trước tiên, hãy chú ý đến các yêu cầu bảo vệ quyền riêng tư, cân nhắc tầm quan trọng và độ nhạy cảm của dữ liệu, sau đó đi sâu vào kho công nghệ, xem xét hiệu quả và chi phí của các thuật toán khác nhau, đồng thời kết hợp các rủi ro và lợi ích hiện tại và tương lai để chọn một chiến lược phù hợp để bảo vệ đầy đủ dữ liệu và Quyền riêng tư, phát triển kinh doanh một cách an toàn và bảo vệ quyền và lợi ích của chính nó và người dùng.