Phần khó nhất của một dự án blockchain doanh nghiệp không phải viết hợp đồng thông minh — phần đó thường là phần nhỏ nhất. Phần khó là nối nó với những hệ thống đã chạy nhiều năm, xử lý việc dữ liệu tồn tại ở hai nơi với hai tốc độ khác nhau, và đảm bảo rằng khi một bên hỏng thì bên kia không sinh ra dữ liệu sai. Bài này trình bày sáu quyết định kiến trúc cần chốt trước khi viết dòng mã đầu tiên.
Bài này giả định bạn đã trả lời xong câu hỏi có nên dùng blockchain hay không. Nếu chưa, hãy đọc blockchain cho doanh nghiệp: khi nào nên và khi nào không trước — phần lớn dự án nên dừng lại ở đó.
Quyết định 1: Cái gì lên chuỗi, cái gì ở lại
Đây là quyết định quan trọng nhất và nó định hình toàn bộ phần còn lại.
Nguyên tắc chung: đưa lên chuỗi càng ít càng tốt. Chỉ những gì thật sự cần bằng chứng không sửa được mới lên chuỗi. Mọi thứ khác ở lại cơ sở dữ liệu thông thường.
Lý do không chỉ là chi phí. Dữ liệu đã lên chuỗi thì gần như không xoá được — và điều đó xung đột trực tiếp với các yêu cầu về quyền riêng tư và quyền được xoá dữ liệu cá nhân. Đưa thông tin cá nhân lên chuỗi là một quyết định rất khó đảo ngược.
Mô hình thường dùng:
Loại dữ liệu | Nơi lưu | Lý do |
|---|---|---|
Nội dung đầy đủ của bản ghi | Cơ sở dữ liệu thông thường | Nhanh, rẻ, sửa và xoá được |
Dấu vân tay của bản ghi | Trên chuỗi | Đủ để chứng minh bản ghi không bị sửa |
Thời điểm ghi | Trên chuỗi | Bằng chứng về thứ tự thời gian |
Danh tính bên ghi | Trên chuỗi, dạng định danh không tiết lộ thông tin cá nhân | Biết ai ghi mà không lộ thông tin |
Tệp đính kèm, ảnh, tài liệu | Lưu trữ ngoài, chỉ đưa dấu vân tay lên chuỗi | Dung lượng lớn, chi phí trên chuỗi quá cao |
Thông tin cá nhân | Không bao giờ lên chuỗi | Không xoá được |
Câu hỏi kiểm tra thiết kế của bạn: nếu ngày mai một người yêu cầu xoá toàn bộ dữ liệu cá nhân của họ, bạn làm được không? Nếu câu trả lời là không vì dữ liệu đã lên chuỗi, thiết kế cần sửa lại.
Quyết định 2: Nguồn dữ liệu nào là nguồn đúng
Khi dữ liệu tồn tại ở hai nơi — cơ sở dữ liệu và chuỗi — bạn phải quyết định nơi nào là nguồn được coi là đúng khi hai bên lệch nhau.
Hai bên sẽ lệch nhau. Giao dịch trên chuỗi có thể chậm, có thể thất bại, có thể được xác nhận sau khi ứng dụng đã báo thành công. Không thiết kế trước cho tình huống này là nguyên nhân của phần lớn lỗi dữ liệu trong hệ thống loại này.
Ba mô hình phổ biến:
Chuỗi là nguồn đúng. Cơ sở dữ liệu chỉ là bản sao để đọc nhanh. Mọi thay đổi ghi lên chuỗi trước, rồi đồng bộ xuống. An toàn nhất về tính toàn vẹn, chậm nhất về trải nghiệm người dùng.
Cơ sở dữ liệu là nguồn đúng, chuỗi là lớp chứng minh. Ghi vào cơ sở dữ liệu trước, rồi định kỳ đưa dấu vân tay lên chuỗi. Nhanh và rẻ, nhưng có khoảng thời gian dữ liệu chưa được bảo chứng.
Mô hình hỗn hợp theo loại dữ liệu. Những bản ghi quan trọng đi theo mô hình thứ nhất, phần còn lại theo mô hình thứ hai. Phức tạp hơn nhưng thường là mô hình thực tế nhất.
Điều phải quyết cùng lúc: khi giao dịch trên chuỗi thất bại sau khi người dùng đã thấy thông báo thành công, hệ thống xử lý thế nào. Tự thử lại, hay đánh dấu chờ xử lý, hay hoàn tác. Không có phương án đúng chung — nhưng phải có phương án.
Quyết định 3: Dữ liệu từ thế giới thực vào chuỗi bằng cách nào
Hợp đồng thông minh không tự biết gì về thế giới bên ngoài. Nó không biết hàng đã giao chưa, nhiệt độ kho là bao nhiêu, hay đối tác đã ký chưa. Ai đó phải đưa thông tin đó vào.
Thành phần làm việc này thường gọi là cầu nối dữ liệu. Và nó là điểm yếu nhất của toàn bộ hệ thống.
Lý do: mọi đảm bảo về tính không sửa được của blockchain chỉ áp dụng cho dữ liệu sau khi đã ghi. Nếu cầu nối dữ liệu đưa vào thông tin sai — do lỗi, do bị tấn công, hoặc do người nhập cố tình — hệ thống sẽ ghi nhận cái sai đó một cách rất đáng tin cậy.
Ba câu hỏi cần trả lời:
Ai được phép ghi dữ liệu vào? Càng ít bên càng dễ kiểm soát, nhưng càng tập trung thì càng mất đi lý do dùng blockchain. Đây là đánh đổi phải cân nhắc rõ.
Có cơ chế đối chiếu nhiều nguồn không? Với dữ liệu quan trọng, yêu cầu nhiều bên độc lập cùng xác nhận trước khi ghi là cách giảm rủi ro hiệu quả nhất.
Xử lý thế nào khi phát hiện dữ liệu đã ghi là sai? Không xoá được, nên cần cơ chế ghi bản đính chính và đánh dấu bản cũ là không còn hiệu lực. Thiết kế cơ chế này từ đầu, không đợi tới khi cần.
Với dữ liệu từ cảm biến hoặc thiết bị: cần tính tới khả năng thiết bị bị can thiệp vật lý. Một cảm biến nhiệt độ bị đặt sai chỗ sẽ ghi nhận số liệu đẹp mà không ai phát hiện qua hệ thống.
Quyết định 4: Quản lý khoá và danh tính
Trong hệ thống blockchain, khoá riêng tư là danh tính. Mất khoá là mất quyền, và không có cơ chế đặt lại mật khẩu.
Với hệ thống doanh nghiệp, điều này tạo ra những vấn đề vận hành rất thực tế mà ít ai tính trước.
Những tình huống cần có phương án từ đầu:
Nhân viên giữ khoá nghỉ việc
Thiết bị chứa khoá bị mất hoặc hỏng
Cần nhiều người cùng phê duyệt một thao tác quan trọng
Cần thu hồi quyền của một bên tham gia
Cần chuyển quyền khi doanh nghiệp tái cấu trúc
Hai hướng tiếp cận:
Người dùng tự giữ khoá. Đúng tinh thần phi tập trung nhưng gần như không khả thi với nhân viên văn phòng. Tỉ lệ mất khoá rất cao.
Doanh nghiệp quản lý khoá tập trung. Thực tế hơn với hệ thống nội bộ, nhưng cần hạ tầng bảo mật riêng cho việc lưu trữ khoá, và cần chấp nhận rằng đơn vị giữ khoá có quyền rất lớn.
Cơ chế nên có với thao tác quan trọng: yêu cầu nhiều chữ ký. Không cá nhân nào một mình thực hiện được thao tác ảnh hưởng lớn. Đây là cơ chế ánh xạ khá tự nhiên với quy trình phê duyệt vốn có của doanh nghiệp.
Quyết định 5: Nâng cấp và sửa lỗi
Phần mềm thông thường sửa lỗi bằng cách triển khai bản mới. Hợp đồng thông minh thì không.
Mã đã triển khai lên chuỗi không sửa được. Nếu có lỗi, bạn cần một cơ chế đã được thiết kế sẵn để thay thế — và cơ chế đó phải có từ đầu, không thêm vào sau.
Ba phương án thường dùng:
Không cho nâng cấp. Đơn giản nhất, an toàn nhất về mặt tin cậy, nhưng mọi lỗi đều vĩnh viễn. Chỉ hợp lý với hợp đồng rất đơn giản đã được kiểm định kỹ.
Cơ chế uỷ quyền. Một hợp đồng cố định làm điểm vào, trỏ tới hợp đồng chứa logic có thể thay thế. Linh hoạt nhưng thêm độ phức tạp và thêm bề mặt tấn công.
Triển khai phiên bản mới và di chuyển dữ liệu. Rõ ràng về mặt khái niệm nhưng tốn công và cần mọi bên tham gia chuyển theo.
Điểm cần cân nhắc: mọi cơ chế cho phép nâng cấp đều có nghĩa ai đó có quyền thay đổi luật chơi sau khi các bên đã tham gia. Ai giữ quyền đó và cần bao nhiêu chữ ký để dùng nó là câu hỏi quản trị, không phải kỹ thuật — và nên được ghi trong thoả thuận giữa các bên, không chỉ trong mã.
Quyết định 6: Kiểm định và môi trường thử nghiệm
Kiểm định bảo mật độc lập là khoản không cắt được với hợp đồng thông minh xử lý giá trị thật. Khác với phần mềm thông thường, lỗi ở đây thường không sửa được sau khi phát hiện, và hậu quả có thể là mất mát không thu hồi.
Những gì nên có trước khi triển khai lên môi trường thật:
Kiểm thử tự động bao phủ mọi nhánh logic của hợp đồng
Chạy đầy đủ trên môi trường thử nghiệm với dữ liệu gần giống thật
Kiểm định bởi bên thứ ba độc lập
Kịch bản xử lý sự cố đã được diễn tập, không chỉ viết ra
Về môi trường thử nghiệm: cần một môi trường tách biệt hoàn toàn, nơi đội phát triển triển khai và huỷ thoải mái. Đây là phần hay bị cắt để tiết kiệm và là khoản tiết kiệm tệ nhất trong dự án loại này.
Kiến trúc tham chiếu
Một hệ thống blockchain doanh nghiệp điển hình có năm lớp:
Lớp | Nhiệm vụ | Công nghệ thường dùng |
|---|---|---|
Giao diện người dùng | Người dùng thao tác, không cần biết có blockchain bên dưới | Web hoặc ứng dụng di động thông thường |
Ứng dụng và nghiệp vụ | Xử lý logic, phân quyền, xác thực người dùng | Nền tảng phát triển thông thường |
Cơ sở dữ liệu | Lưu trữ chính, phục vụ truy vấn nhanh | Cơ sở dữ liệu quan hệ hoặc tài liệu |
Lớp cầu nối | Ký giao dịch, gửi lên chuỗi, theo dõi trạng thái, xử lý lỗi | Dịch vụ riêng, thường là phần phức tạp nhất |
Chuỗi | Lưu bằng chứng không sửa được | Mạng công khai hoặc mạng riêng |
Nguyên tắc thiết kế quan trọng nhất: người dùng cuối không nên biết có blockchain bên dưới. Nếu nhân viên kho phải hiểu khái niệm khoá riêng tư để làm việc, hệ thống sẽ không được dùng.
Lớp tốn công nhất: lớp cầu nối. Nó phải xử lý mọi tình huống bất thường — giao dịch chậm, thất bại, bị thay thế, hoặc được xác nhận rồi lại bị đảo. Phần lớn thời gian phát triển thực tế nằm ở đây chứ không nằm ở hợp đồng thông minh.
Nếu đội của bạn đang chuẩn bị bắt đầu một dự án loại này, sáu quyết định ở trên nên được chốt bằng văn bản trước khi viết dòng mã đầu tiên. Thay đổi bất kỳ quyết định nào trong số đó ở giữa dự án đều tốn kém hơn nhiều so với dành thêm hai tuần ở giai đoạn thiết kế. Xem cách chúng tôi tiếp cận tại dịch vụ phát triển blockchain.
Ba điểm thường làm dự án chậm hoặc hỏng
Đánh giá thấp phần tích hợp
Phần lớn báo giá và kế hoạch tập trung vào hợp đồng thông minh, trong khi phần này thường chỉ chiếm một tỉ lệ nhỏ khối lượng công việc thật. Lớp cầu nối, xử lý lỗi, đồng bộ dữ liệu và di chuyển dữ liệu cũ chiếm phần lớn hơn nhiều.
Cách phòng: khi nhận báo giá, hỏi cụ thể phần trăm khối lượng dành cho tích hợp. Một báo giá chỉ nói về hợp đồng thông minh là báo giá chưa tính đủ.
Không xử lý dữ liệu đã có
Hệ thống mới gần như luôn phải làm việc với dữ liệu cũ. Đưa toàn bộ lịch sử lên chuỗi thường không khả thi về chi phí, và cũng không có giá trị vì không ai chứng minh được dữ liệu cũ là đúng tại thời điểm ghi.
Cách làm thường hợp lý: chốt một mốc thời gian, từ mốc đó trở đi mới có bằng chứng trên chuỗi, và nói rõ điều này với mọi bên tham gia.
Bỏ qua trải nghiệm người dùng nội bộ
Hệ thống đúng kỹ thuật nhưng người vận hành thấy phiền hơn cách cũ sẽ không được dùng. Nhân viên sẽ tìm đường vòng, và dữ liệu trên chuỗi sẽ không phản ánh thực tế.
Dấu hiệu cần chú ý trong giai đoạn thử nghiệm: nếu người dùng phải chờ, phải thao tác thêm bước, hoặc phải nhớ thêm thứ gì đó so với quy trình cũ, tỉ lệ sử dụng thật sẽ thấp.
Câu hỏi thường gặp
Hợp đồng thông minh chiếm bao nhiêu phần khối lượng dự án? Thường là phần nhỏ. Lớp cầu nối, tích hợp với hệ thống hiện có và xử lý các tình huống bất thường chiếm phần lớn hơn nhiều.
Có thể thêm blockchain vào hệ thống đang chạy mà không sửa gì không? Về lý thuyết là có nếu chỉ đưa dấu vân tay lên chuỗi theo lô. Thực tế vẫn cần sửa để hệ thống biết bản ghi nào đã được bảo chứng và bản ghi nào chưa.
Mạng riêng có cần kiểm định bảo mật không? Có, nếu hợp đồng thông minh xử lý giá trị hoặc quyền quan trọng. Mạng riêng giảm rủi ro từ bên ngoài nhưng không giảm rủi ro từ lỗi logic trong mã.
Chi phí vận hành hằng tháng gồm những gì? Hạ tầng chạy các nút hoặc dịch vụ thay thế, chi phí giao dịch nếu dùng mạng công khai, chi phí lưu trữ ngoài chuỗi, và nhân sự vận hành. Khoản cuối thường bị quên khi lập ngân sách.
Đội phát triển hiện tại có làm được không? Phần lớn khối lượng công việc là phát triển thông thường mà đội hiện có làm được. Phần chuyên biệt là hợp đồng thông minh và lớp cầu nối — hai phần này cần kinh nghiệm riêng, đặc biệt ở khâu xử lý lỗi.
Nếu sau này muốn bỏ blockchain thì sao? Nên thiết kế sao cho điều đó khả thi: giữ cơ sở dữ liệu thông thường làm nơi lưu trữ đầy đủ, và coi lớp chuỗi là lớp bổ sung có thể tháo ra. Thiết kế phụ thuộc hoàn toàn vào chuỗi sẽ khoá bạn lại.
Bước tiếp theo
Trước khi bắt đầu, viết ra câu trả lời cho sáu quyết định ở trên và cho cả đội cùng đọc. Phần lớn xung đột giữa chừng của dự án loại này bắt nguồn từ việc các bên hiểu khác nhau về quyết định số 1 và số 2.
Nếu có bất kỳ quyết định nào chưa trả lời được, đó là dấu hiệu cần thêm thời gian ở giai đoạn thiết kế chứ không phải dấu hiệu cần bắt đầu viết mã để "vừa làm vừa rõ".
Cần trao đổi về kiến trúc cho hệ thống cụ thể của bạn, liên hệ Tấn Phát Digital.
