Có một nhà phát triển đã tuyên bố rằng blockchain chỉ là các cơ sở dữ liệu “tồi tệ”. Tại sao không sử dụng PostgreSQL cho ứng dụng của bạn? Nó đạt được sự trưởng thành, mạnh mẽ và hiệu suất cao. So với các cơ sở dữ liệu có mối quan hệ, những người hoài nghi tuyên bố rằng các blockchain chỉ là các cơ sở dữ liệu chậm chạp, cồng kềnh và đắt tiền mà không hệ mở rộng quy mô.
Mặc dù đã xuất hiện một số bài phê bình, tôi xin đề xuất một phản bác đơn giản bằng một câu: blockchain công khai rất hữu ích để lưu trữ trạng thái chia sẻ, đặc biệt khi trạng thái chia sẻ đó thể hiện dữ liệu có giá trị mà người dùng muốn xuất/nhập mà không xảy ra lỗi (error) – như tiền của họ.
Vấn đề xuất / nhập dữ liệu
Hãy cùng quan sát sơ đồ đám mây cho Amazon Web Services, Microsoft Azure hoặc Google Cloud. Có các biểu tượng cho bộ cân bằng tải (load balancers), bộ chuyển mã, hàng đợi (queues) và hàm lambda.
Có các biểu tượng cho VPC và mọi loại cơ sở dữ liệu, bao gồm các dịch vụ blockchain mới được quản lý (khác với các blockchain công khai, mặc dù có thể hữu ích trong một số trường hợp).
Thứ mà không có biểu tưởng đó là trạng thái được chia sẻ giữa các tài khoản. Đó là, tất cả các sơ đồ đám mây đều mặc nhiên cho rằng, một thực thể và nhân viên của nó (cụ thể là thực thể có quyền truy cập vào tài khoản gốc trên đám mây) là người duy nhất đưa ra sơ đồ kiến trúc và đọc từ hoặc ghi vào ứng dụng mà nó làm cơ sở cho. Chính xác hơn, các sơ đồ này thường giả định sự hiện diện của một tác nhân kinh tế duy nhất, cụ thể là thực thể thanh toán hóa đơn đám mây. *
Nhưng nếu chúng ta hình dung các sơ đồ đám mây cho không chỉ một mà một trăm chủ thể kinh tế doanh nghiệp tại một thời điểm, một số câu hỏi ngay lập tức xuất hiện. Liệu những thực thể này có thể tương tác? Người dùng của chúng có thể lấy dữ liệu của họ ra và đưa nó vào các ứng dụng khác không? Và giả sử chính người dùng là tác nhân kinh tế, nếu dữ liệu này đại diện cho thứ gì đó có giá trị tiền tệ, liệu người dùng có thể tự tin rằng dữ liệu của họ đã được sửa đổi trong suốt quá trình xuất và nhập này không?
Đây là những loại câu hỏi phát sinh khi chúng ta nghĩ về việc xuất và nhập dữ liệu từ mỗi ứng dụng thực thể như một yêu cầu hạng nhất. Và (với các trường hợp ngoại lệ mà chúng ta sẽ nhận được), nói chung, câu trả lời cho những câu hỏi này ngày nay thường là không.
Không – các ứng dụng khác nhau thường không có phần mềm có thể tương tác hoặc cho phép người dùng của chúng dễ dàng xuất/nhập dữ liệu của họ ở dạng chuẩn, hoặc cung cấp cho người dùng sự chắc chắn rằng dữ liệu của họ không bị giả mạo hoặc vô tình bị hỏng trong quá trình xuất và nhập .
Lý do tại sao nằm ở các khuyến khích. Đối với hầu hết các dịch vụ internet lớn, đơn giản là không có động cơ tài chính để cho phép người dùng xuất dữ liệu của họ, chứ chưa nói đến việc cho phép các đối thủ cạnh tranh nhanh chóng nhập dữ liệu nói trên. Trong khi một số người gọi đây là vấn đề về tính di động của dữ liệu, thì hãy gọi nó là vấn đề xuất/nhập dữ liệu để tập trung sự chú ý vào các cơ chế cụ thể để xuất và nhập.
Cách tiếp cận hiện tại cho vấn đề xuất / nhập dữ liệu
Mặc dù các khuyến khích tài chính chưa xuất hiện cho để giải quyết vấn đề xuất/nhập dữ liệu, các cơ chế đã được tạo ra cho nhiều trường hợp đặc biệt quan trọng. Các cơ chế này bao gồm API, xuất JSON / PDF / CSV, tệp MBOX và SFTP (trong bối cảnh ngân hàng).
Hãy lần lượt đi qua các cơ chế này để hiểu tình trạng hiện tại.
API. Một trong những cách phổ biến nhất để xuất/nhập dữ liệu là thông qua Giao diện lập trình ứng dụng, được gọi là API. Một số doanh nghiệp cho phép bạn lấy một số dữ liệu của mình, hoặc cung cấp cho bạn khả năng ghi dữ liệu vào tài khoản của bạn. Nhưng sẽ có một khoản chi phí. Đầu tiên, định dạng dữ liệu nội bộ của họ thường là độc quyền và không phải là một tiêu chuẩn công nghiệp. Thứ hai, đôi khi các API không phải là trung tâm trong hoạt động kinh doanh cốt lõi của họ và có thể bị tắt. Thứ ba, đôi khi các API là trọng tâm trong hoạt động kinh doanh cốt lõi của họ, và giá có thể được tăng lên đáng kể. Nói chung, nếu bạn đọc hoặc ghi vào API được lưu trữ, bạn sẽ phải chịu sự kiểm soát của nhà cung cấp API. Chúng tôi gọi rủi ro nền tảng này và việc hủy nền tảng một cách kỳ lạ đã gây hại cho nhiều startup.
JSON. Một giải pháp liên quan khác là cho phép người dùng hoặc tập lệnh tải xuống các tệp JSON hoặc đọc/ghi chúng vào các API đã nói ở trên. Điều này vẫn tốt cho đến thời điểm hiện tại, nhưng JSON là hình thức miễn phí và có thể mô tả gần như mọi thứ. Ví dụ: Graph API của và API REST API của LinkedIn xử lý các vấn đề tương tự nhưng trả về các kết quả JSON rất khác nhau.
PDF. Một giải pháp rất riêng khác là cho phép người dùng xuất PDF. Điều này hoạt động đối với các tài liệu, vì PDF là một tiêu chuẩn mở có thể được đọc bởi các ứng dụng khác như Preview, Adobe Acrobat, Google Drive, Dropbox, v.v. Nhưng một bản PDF phải là một sản phẩm cuối cùng, được đọc bởi một con người. Nó không có nghĩa là một đầu vào cho bất kỳ ứng dụng nào ngoài trình xem PDF.
CSV. Tệp giá trị được phân tách bằng dấu phẩy khiêm tốn tiến gần hơn đến những gì chúng ta muốn cho một giải pháp chung cho vấn đề nhập/xuất dữ liệu. Không giống như phần backend của API độc quyền, CSV là định dạng chuẩn được mô tả bởi RFC 4180. Không giống như JSON, có thể đại diện cho hầu hết mọi thứ, CSV thường chỉ đại diện cho một bảng. Và không giống như PDF, CSV thường có thể được chỉnh sửa cục bộ bởi người dùng thông qua bảng tính hoặc được sử dụng làm đầu vào có thể đọc được bằng máy cho ứng dụng cục bộ hoặc đám mây. Bởi vì hầu hết các loại dữ liệu có thể được biểu diễn trong cơ sở dữ liệu quan hệ, và vì cơ sở dữ liệu quan hệ thường có thể được xuất dưới dạng một tập hợp các CSV khổng lồ khả thi, nên nó cũng khá chung chung. Tuy nhiên, CSV bị bất lợi theo một số cách. Đầu tiên, không giống như một API độc quyền, chúng được lưu trữ trên máy chủ. Đó là, không có nơi nào để đọc hoặc viết một CSV biểu thị (giả sử) một bản ghi các giao dịch hoặc một bảng siêu dữ liệu bản đồ. Thứ hai, CSV không có khả năng chống giả mạo. Nếu người dùng xuất một bản ghi của các giao dịch từ dịch vụ A, sửa đổi nó và tải lại nó cho dịch vụ B, dịch vụ thứ hai sẽ không phải là dịch vụ khôn ngoan hơn. Thứ ba, các CSV không được tích hợp kiểm tra tính toàn vẹn để bảo vệ chống lại các lỗi sơ xuất. Ví dụ: các cột của một CSV không có loại thông tin rõ ràng, có nghĩa là một cột chứa các tháng trong năm từ 1-12 có thể tự động chuyển đổi loại khi nhập vào một số nguyên đơn giản, dễ gây nhầm lẫn.
MBOX. Mặc dù ít được biết đến hơn CSV, định dạng MBOX để thể hiện các bộ sưu tập thư email là thứ gần nhất với cấu trúc dữ liệu được tiêu chuẩn hóa được xây dựng để nhập và xuất giữa các nền tảng chính và các ứng dụng độc lập. Thật vậy, đã có những bài báo đề xuất sử dụng MBOX trong trường hợp bên ngoài email. Trong khi CSV biểu thị dữ liệu dạng bảng, MBOX đại diện cho một loại dữ liệu có cấu trúc nhật ký. Nó về cơ bản là một tệp văn bản khổng lồ đơn giản của các email theo thứ tự thời gian, nhưng cũng có thể biểu thị các tệp đính kèm hình ảnh/tệp qua MIME. Giống như CSV, các tệp MBOX là một tiêu chuẩn mở và có thể được xuất, chỉnh sửa cục bộ và nhập lại. Và giống như CSV, MBOX có nhược điểm là không có máy chủ chính thức hoặc kiểm tra tính toàn vẹn dữ liệu nội tại.
SFTP. Trước khi chúng ta tiếp tục, có thêm một cơ chế xuất/nhập dữ liệu đáng được đề cập: giao thức truyền tệp an toàn, hay được gọi là SFTP. Mặc dù rất đáng xem xét, đây thực sự là cách mà các cá nhân gửi thanh toán ACH qua lại với nhau. Về cơ bản, các tổ chức tài chính sử dụng máy chủ SFTP để lấy dữ liệu giao dịch điện tử trong các tệp được định dạng đặc biệt, và truyền dữ liệu đến Cục Dự trữ Liên bang mỗi ngày để đồng bộ hóa các khoản nợ và tín dụng ACH với nhau.
Mỗi cơ chế này được sử dụng rộng rãi. Nhưng chúng không đủ để cho phép trường hợp chung về nhập và xuất dữ liệu có giá trị giữa các chủ thể kinh tế độc đoán – cho dù họ là thực thể công ty, người dùng cá nhân hoặc tập lệnh ‘không có giao diện đồ họa người dùng’ (headless scripts). Và chính vì điều đó, chúng ta sẽ cần đến các blockchain công khai.
Blockchains công khai cho phép trạng thái được chia sẻ bằng cách khuyến khích khả năng tương tác. Các blockchain công khai chuyển đổi nhiều loại vấn đề nhập/xuất dữ liệu thành một lớp chung của các vấn đề trạng thái chia sẻ. Và chúng làm như vậy một phần bằng cách kết hợp nhiều tính năng tốt nhất của các cơ chế được mô tả ở trên.
- Các blockchain công khai cung cấp các phương thức chính thức để truy cập đọc/ghi như API công ty được lưu trữ, nhưng không có rủi ro nền tảng tương tự. Không một tác nhân kinh tế nào có thể dập tắt hoặc từ chối dịch vụ cho các khách hàng của một blockchain công khai phi tập trung như bitcoin hoặc ethereum.
- Chúng cũng cho phép người dùng cá nhân xuất dữ liệu quan trọng sang máy tính cục bộ của họ hoặc sang một ứng dụng mới như JSON/CSV/MBOX (bằng cách gửi tiền hoặc xuất khóa riêng) trong khi cung cấp bảo đảm về mật mã hóa tính toàn vẹn của dữ liệu.
- Chúng cung cấp một phương tiện cho các chủ thể kinh tế độc đoán (cho dù là các tập đoàn, người dùng cá nhân hoặc chương trình) để liên tục hoạt động. Mọi tác nhân kinh tế đọc từ một blockchain công khai đều thấy kết quả tương tự và bất kỳ tác nhân kinh tế nào có đủ tiền đều có thể viết cho một blockchain công khai theo cùng một cách. Không cần thiết lập tài khoản và không có tác nhân nào có thể bị chặn truy cập đọc/ghi.
- Và có lẽ quan trọng nhất, các blockchain công khai cung cấp các khuyến khích tài chính cho khả năng tương tác và tính toàn vẹn dữ liệu.
Điểm cuối cùng nhưng không kém phần quan trọng. Một blockchain công khai như bitcoin hoặc ethereum thường ghi lại việc chuyển những thứ có giá trị tiền tệ. Thứ này có thể là tiền điện tử nội tại của chuỗi, token được phát hành trên đầu chuỗi hoặc một loại tài sản kỹ thuật số khác.
Bởi vì dữ liệu được liên kết với một blockchain công khai đại diện cho thứ gì đó có giá trị tiền tệ, cuối cùng nó mang lại động lực tài chính cho khả năng tương tác. Rốt cuộc, bất kỳ ứng dụng web hoặc ứng dụng di động nào muốn nhận, giả sử như BTC đều phải tôn trọng các quy ước blockchain bitcoin. Thật vậy, các nhà phát triển ứng dụng sẽ không có lựa chọn nào do thực tế là bitcoin theo thiết kế có một chuỗi proof-of-work dài nhất, với xác thực mã hóa của mọi khối trong chuỗi đó.
Và đó là các khuyến khích tài chính cho hoạt động nhập.
Đối với các khuyến khích cho hoạt độn xuất, khi nói đến tiền, người dùng yêu cầu khả năng xuất với độ trung thực hoàn toàn, và rất nhanh chóng. Nó không phải là một bức ảnh vè chú mèo cũ của họ, mà họ có thể ổn với việc mất dấu vết do sự bất tiện hoặc các vấn đề kỹ thuật. Mà đó là tiền của họ, bitcoin, tiền điện tử của họ. Bất kỳ ứng dụng nào nắm giữ nó phải có sẵn để xuất khi họ muốn rút, cho dù điều đó có nghĩa là hỗ trợ chức năng gửi, cung cấp sao lưu khóa riêng hoặc cả hai. Nếu không, ứng dụng không có khả năng nhận tiền gửi ngay từ đầu.
Và đó là các khuyến khích tài chính cho hoạt động xuất. Do đó, một blockchain công khai khuyến khích tài chính cho mọi tác nhân kinh tế tương tác với nó để sử dụng định dạng nhập/xuất giống như mọi tác nhân khác, cho dù họ là tập đoàn, người dùng hoặc chương trình. Nói cách khác, các blockchain công khai là bước tiếp theo sau nguồn mở, vì chúng cung cấp dữ liệu mở. Bất cứ ai cũng có thể mã hóa trình thám hiểm khối của riêng mình bằng cách đọc từ một blockchain công khai, và bất kỳ ai cũng có thể tạo ví của riêng mình có khả năng viết lên blockchain công khai.
Đó là một bước đột phá thực sự. Bây giờ chúng ta đã có một cách đáng tin cậy để khuyến khích việc sử dụng trạng thái chia sẻ, đồng thời cho phép hàng triệu cá nhân và công ty truy cập để đọc từ (và hàng ngàn để ghi vào) cùng một kho lưu trữ dữ liệu trong khi thực thi một tiêu chuẩn chung và duy trì độ tin cậy cao đối với tính toàn vẹn của dữ liệu.
Điều này rất khác với hiện trạng. Bạn thường không chia sẻ mật khẩu gốc vào cơ sở dữ liệu của mình trên internet, bởi vì cơ sở dữ liệu cho phép mọi người đọc/ghi vào nó thường bị hỏng. Các blockchain công khai giải quyết vấn đề này bằng mật mã thay vì sự cho phép, làm tăng đáng kể số lượng người dùng.
Đúng là ngày nay các blockchain công khai thường tập trung vào các ứng dụng tài chính và tiền tệ, trong đó bộ dữ liệu cơ bản thể hiện lịch sử giao dịch chỉ nối với các hồ sơ bất biến. Điều đó không giới hạn tính tổng quát của chúng, về mặt giải quyết tất cả các phiên bản khác nhau của vấn đề nhập/xuất dữ liệu. Tuy nhiên, có sự phát triển liên tục trên các phiên bản blockchain công khai của những thứ như OpenStreetMaps, Wikipedia và Twitter cũng như các hệ thống như Filecoin/IPFS. Những thứ này sẽ chỉ đại diện cho các hồ sơ về các giao dịch tài chính trong đó tính bất biến là một yêu cầu, nhưng có thể đại diện cho các loại dữ liệu khác (như mục nhập bản đồ hoặc bách khoa toàn thư) sẽ được cập nhật thường xuyên.
Hoàn thành đúng, các loại hệ thống dựa trên blockchain công khai mới hơn này có thể cho phép bất kỳ tác nhân kinh tế nào có đủ tiền và/hoặc thông tin mật mã không chỉ đọc và viết, mà còn chỉnh sửa hồ sơ của chính họ trong khi duy trì tính toàn vẹn dữ liệu. Với khả năng này, không có lý do gì mà người ta có thể đặt một lớp SQL lên trên một blockchain công khai để làm việc với trạng thái chia sẻ mà nó có, giống như một cơ sở dữ liệu quan hệ kiểu cũ. Điều này dẫn đến một loại cơ sở dữ liệu mới không có chủ sở hữu đặc quyền, trong đó tất cả bảy tỷ người trên hành tinh (và tập lệnh của họ!) là những người dùng được ủy quyền và có thể được viết bởi bất kỳ thực thể nào có đủ tiền.
Ngày đó vẫn chưa đến. Vẫn còn phải xem chúng ta có thể đẩy các trường hợp sử dụng cho các chuỗi công khai đi bao xa. Và những thách thức về mở rộng vẫn rất nhiều. Nhưng hy vọng, nó rõ ràng rằng mặc dù các blockchain công khai thực sự là một loại cơ sở dữ liệu mới, chúng cung cấp một cái gì đó hoàn toàn khác so với những gì một cơ sở dữ liệu truyền thống cung cấp.
