Cấu trúc cơ bản của ứng dụng Web3.0

Mục Lục

Trong bài viết này, mình sẽ cung cấp cho anh em thông tin về cấu trúc cơ bản của ứng dụng Web3.0. Bài viết có nhiều yếu tố học thuật nhưng mình hi vọng anh em có thể hình dung được phần nào. Từ đó khi đọc về các dự án cơ sở hạ tầng của Web3 sẽ dễ dàng hình dung dự án đó đang giải quyết vấn đề gì? có thực sự cần thiết không?

Sơ lược về cấu trúc Web2.0

Để tiếp cận Web3 nhanh chóng hơn, chúng ta hãy cùng đi sơ lược về cấu trúc Web2 – trang web mà chúng ta vẫn đang sử dụng hàng ngày. Qua đó, anh em sẽ thấy các ứng dụng của Web3.0 (hay “Dapp”) hoàn toàn khác với các ứng dụng Web2.0

Lấy Medium là ví dụ cho một web blog mà anh em vẫn truy cập để tương tác với nội dung của người khác đồng thời có thể xuất bản nội dung ở trên đó. Đây là ứng dụng Web2.0 nghe có vẻ đơn giản nhưng có rất nhiều thứ trong cấu trúc của web blog này để chúng ta cùng xem xét:

  • Đầu tiên, khi người dùng tương tác với web blog thông qua việc đăng bài, nhận xét, lượt thích…sẽ cần có một nơi để lưu trữ dữ liệu cần thiết. Điều này sẽ yêu cầu cơ sở dữ liệu được cập nhật liên tục.
  • Thứ hai, sẽ có một phần code dưới backend xử lý các vấn đề nghiệp vụ của web blog ví dụ: hành động gì xảy ra tiếp theo khi người dùng mới đăng ký hoặc xuất bản một bài blog hoặc gõ mất dòng comment hoặc bất cứ tương tác gì trên blog.
  • Thứ ba là giao diện người dùng (front-end) phải xác định logic giao diện người dùng trông sẽ như thế nào? và điều gì xảy ra khi người dùng tương tác với các phần tử trên web

Tóm lại, khi anh em tương tác với bài đăng trên blog Medium tương đương với việc tác động vào front-end. Front-end sau khi nhận được tương tác sẽ gửi yêu cầu lưu trữ bình luận xuống back-end. Back-end xử lý dữ liệu và lưu trữ trên một máy chủ tập trung và trả kết quả cho front-end, front-end sẽ gửi thông báo đến người dùng thông qua trình duyệt Internet. Đây là tóm tắt đơn giản về cách hoạt động hầu hết các ứng dụng Web2.0 ngày nay.

Nhưng tất cả các hoạt động trên đang được thay đổi trên Web3.0. Ứng dụng công nghệ Blockchain đã mở ra hướng đi mới thú vị cho các ứng dụng Web3.0. Chúng ta sẽ tập trung vào cấu trúc ứng dụng Web3.0 trên blockchain Ethereum (do Ethereum là blockchain phổ biến và có nhiều Dapp được xây dựng trên nó nhất)

Điều gì làm cho Web3.0 khác biệt?

Không giống các ứng dụng Web2.0, Web3.0 sẽ loại bỏ đi trung gian không cần thiết. Không có cơ sở dữ liệu tập trung nào lưu trữ các trạng thái của ứng dụng và không có máy chủ web tập trung nào chứa logic của backend.

Thay vào đó, có thể tận dụng blockchain để xây dựng ứng dụng phi tập trung được duy trì bởi các node ẩn danh trên Internet.

Cấu trúc của Web3.0 cơ bản đầu tiên sẽ như sau:

 

Blockchain

Blockchain Ethereum là các chuỗi khối chạy trên nhiều máy tính. Nó được xác định các trạng thái ban đầu và có thể truy cập toàn cầu đồng thời được duy trì bởi một mạng lưới các nút ngang hàng. Các thay đổi trạng thái trên blockchain được điều chỉnh bởi quy tắc đồng thuận. Và một điều cần lưu ý là chỉ có thể ghi vào blockchain mà không bao giờ có thể sửa và xóa dữ liệu đó được.

Smart Contract

Smart Contract là chương trình chạy trên blockchain, dùng để xác định logic và bài toàn nghiệp vụ của ứng dụng. Thông qua những logic đó sẽ làm kích hoạt sự thay đổi trạng thái của blockchain. Smart Contract sẽ được viết bằng ngôn ngữ lập trình bậc cao như Solidity và Vyper…

Do smart contract được lưu trữ trên blockchain nên bất kỳ ai cũng có thể kiểm tra logic ứng dụng của tất cả các smart contract trên mạng lưới.

Máy ảo Ethereum (EVM)

Tiếp theo Máy ảo Ethereum sẽ thực thi logic được xác định trong các smart contract và xử lý các thay đổi trạng thái xảy ra trên máy trạng thái có thể truy cập toàn cầu này.

EVM không hiểu các ngôn ngữ cấp cao như Solidity và Vyper, được sử dụng để viết các smart contract. Thay vào đó, các nhà phát triển ứng dụng phải biên dịch ngôn ngữ cấp cao thành bytecode để EVM có thể thực thi.

Giao diện người dùng (Front-end)

Frontend của Web3.0 thì hầu như không thay đổi so với Web2.0 ngoài một số ngoại lên để tăng tính phi tập trung của Frontend. (Theo mình thì điều này sẽ khiến người dùng ít phải thay đổi thói quen sử dụng nhất).

Làm thế nào để Front-end giao tiếp với các Smart Contract?

Để tương tác với dữ liệu và code trên blockchain, Frontend sẽ cần tương tác với một trong các nút trên mạng lưới này. Điều này là do bất kỳ nút nào cũng có thể phát yêu cầu giao dịch trên EVM. Sau đó, người khác thác (thợ đào) sẽ thực hiện giao dịch và gửi kết quả thay đổi trạng thái đến các nút còn lại của mạng.

Có hai cách để gửi một giao dịch mới:

  1. Thiết lập nút của riêng để chạy phần mềm chuỗi khối Ethereum
  2. Sử dụng các nút được cung cấp bởi các dịch vụ của bên thứ ba như Infura , AlchemyQuicknode

Nếu sử dụng dịch vụ của bên thứ ba, nhà phát triển sẽ không phải đối mặt với tất cả các vấn đề đau đầu khi tự chạy một nút đầy đủ. Rốt cuộc, việc thiết lập một nút Ethereum mới trên máy chủ của riêng họ có thể mất nhiều ngày. (Có rất nhiều dữ liệu cần đồng bộ – Nó thậm chí có thể chiếm nhiều băng thông và dung lượng hơn so với một máy tính xách tay thông thường có thể xử lý.)

Hơn nữa, chi phí lưu trữ toàn bộ chuỗi khối Ethereum sẽ tăng lên khi DApp của họ mở rộng và họ cần thêm nhiều nút hơn để mở rộng cơ sở hạ tầng. Đó là lý do tại sao, khi cơ sở hạ tầng của các nhà phát triển trở nên phức tạp hơn, họ sẽ cần các kỹ sư DevOps toàn thời gian. Các kỹ sự này sẽ giúp họ duy trì cơ sở hạ tầng để đảm bảo thời gian hoạt động đáng tin cậy và thời gian phản hồi nhanh chóng.

Tất cả những điều đó để nói rằng, tránh được những vấn đề đau đầu này là lý do tại sao nhiều nhà phát triển DApp chọn sử dụng các dịch vụ như Infura hoặc Alchemy để quản lý cơ sở hạ tầng nút cho họ. Tất nhiên, có một sự đánh đổi vì điều này tạo ra một điểm chokepoint tập trung.

Tiếp tục, hãy nói về các nhà cung cấp. Các nút kết nối khi cần tương tác với blockchain (cho dù tự thiết lập chúng hay sử dụng các nút hiện có từ các dịch vụ của bên thứ ba) thường được gọi là “Provider”.

Tuy nhiên, khi người dùng muốn xuất bản một bài đăng mới lên chuỗi, DApp của sẽ yêu cầu người dùng “ký” vào giao dịch bằng khóa riêng của họ – chỉ sau đó DApp mới chuyển giao giao dịch đó sang chuỗi khối. Nếu không, các nút sẽ không chấp nhận giao dịch.

Việc “ký kết” các giao dịch này là nơi mà Metamask thường xuất hiện.

Metamask là một công cụ giúp các ứng dụng dễ dàng xử lý việc quản lý khóa và ký kết giao dịch. Nó khá đơn giản: Metamask lưu trữ các khóa riêng của người dùng trong trình duyệt và bất cứ khi nào giao diện người dùng cần người dùng ký giao dịch, nó sẽ gọi đến Metamask.

Metamask cũng cung cấp kết nối với blockchain (với tư cách là “nhà cung cấp”) vì nó đã có kết nối với các nút do Infura cung cấp vì nó cần nó để ký giao dịch. Theo cách này, Metamask vừa là nhà cung cấp vừa là người ký.

Lưu ý: có thể sử dụng các ví khác để ký tuỳ vào yêu cầu của ứng dụng nhưng hiện này Metamask là phổ biến nhất.

Lưu trữ trên Blockchain

Như đã biết, bất kỳ nhà phát triển nào xây dựng dụng trên Ethereum đều biết rằng việc lưu trữ mọi thứ trên blockchain đều rất tốn kém. Với Ethereum, người dùng cần trả tiền khi thêm dữ liệu mới vào blockchain. Lý do là khi thêm trạng thái vào blockchain sẽ làm tăng thêm các nút mạng để duy trì trạng thái đó.

Tuy nhiên, chúng ta thường e ngại khi sử dụng các Dapp mà phí ETH quá cao. Hoặc một Dapp yêu cầu người dùng trả thêm tiền để sử dụng mỗi khi họ giao dịch là một trải nghiệm không tốt và khó thu hút được nhiều người sử dụng. Do đó, cần một giải pháp lưu trữ tạm thời ngoài chuỗi phi tập trung như IPFS hoặc Swarm

IPFS là một hệ thống tệp phân tán để lưu trữ và truy cập dữ liệu. Vì vậy, thay vì lưu trữ dữ liệu trong cơ sở dữ liệu tập trung, hệ thống IPFS phân phối và lưu trữ dữ liệu trong một mạng ngang hàng. Điều này giúp dễ dàng lấy ra khi cần.

IPFS cũng có một lớp khuyến khích được gọi là “Filecoin”. Lớp này khuyến khích các nút trên khắp thế giới lưu trữ và truy xuất dữ liệu này. Các nhà phát triển có thể sử dụng nhà cung cấp như Infura (cung cấp cho nút IPFS) hoặc Pinata (cung cấp dịch vụ dễ sử dụng, nơi có thể “ghim” các tệp của họ vào IPFS và lấy mã băm IPFS và lưu trữ trên blockchain) .

Swarm tương tự ở chỗ đó là một mạng lưu trữ phi tập trung, nhưng có một điểm khác biệt đáng chú ý. Trong khi Filecoin là một hệ thống riêng biệt, hệ thống khuyến khích của Swarm được tích hợp sẵn và thực thi thông qua các smart contract trên chuỗi khối Ethereum để lưu trữ và truy xuất dữ liệu.

Vì vậy, bây giờ, với IPFS hoặc Swarm, kiến ​​trúc ứng dụng của chúng tôi trông giống như sau:

Tuy nhiên, nếu như sơ đồ trên thì giao diện người dùng đang không được lưu trữ trên blockchain. Các nhà phát triển có thể lưu trữ code trên AWS (Amazon web service) như các Web2.0 thường làm. Câu hỏi đặt ra là điều gì sẽ xảy ra khi AWS gặp sự cố.? Điều gì sẽ xảy ra nếu ứng dụng bị kiểm duyệt. Vì vậy, để xây dựng một ứng dụng phi tập trung thực sự, các nhà phát triển có thể chọn lưu trữ giao diện của mình trên một giải pháp phi tập trung hơn là IPFS hay Swarm.

Vì vậy cấu trúc ứng dụng có thể chuyển sang sơ đồ này:

Truy vấn blockchain

Ở phần trên, chúng ta đã nắm được cách ghi vào blockchain bằng cách ký vào các giao dịch sau đó gửi đến blockchain. Tuy nhiên để Web3 sử dụng linh hoạt thì cần có sự tương tác 2 chiều. Khi cần lấy dữ liệu từ các smart contract trên blockchain thì sẽ làm như thế nào? Có hai cách để thực hiện đó là:

Smart Contract Events

Các nhà phát triển có thể sử dụng thư viện Web3.js để truy vấn và lắng nghe các sự kiện smart contract. Họ có thể nghe các sự kiện cụ thể và chỉ định một lệnh gọi lại mỗi khi sự kiện được kích hoạt.

Ví dụ: nếu có một smart contract gửi một luồng thanh toán liên tục từ người A đến người B mỗi block, thì các nhà phát triển có thể tạo ra một sự kiện mỗi khi một khoản thanh toán mới được thực hiện cho người B. Code Frontend có thể được lập trình để lắng nghe các sự kiện đang được kích hoạt bằng smart contract và thực hiện các hành động cụ thể dựa trên hợp đồng đó.

Tuy nhiên cách này sẽ có một số hạn chế như: điều gì sẽ xảy ra nếu các nhà phát triển triển khai một smart contract và sau đó nhận ra rằng họ cần một sự kiện được phát ra mà ban đầu họ chưa lập trình trên smart contract? Thật không may, các nhà phát triển sẽ phải triển khai lại một smart contract mới với sự kiện và dữ liệu đó. Hơn nữa, việc sử dụng các lệnh gọi lại để xử lý các logic giao diện người dùng khác nhau trở nên rất phức tạp nhanh chóng.

The Graph

The Graph là một giải pháp lập chỉ mục ngoài chuỗi giúp truy vấn dữ liệu trên blockchain Ethereum dễ dàng hơn. Do đó, The Graph cho phép xác định các smart contract nào cần lập chỉ mục, các sự kiện và lệnh gọi hàm nào để lắng nghe và cách chuyển các sự kiện đến thành các thực thể mà logic giao diện người dùng (hoặc bất kỳ thứ gì đang sử dụng API) có thể sử dụng. Nó sử dụng GraphQL làm ngôn ngữ truy vấn, nhiều kỹ sư front-end yêu thích vì nó thực hiện khá giống so với các API REST truyền thống.

Bằng cách lập chỉ mục dữ liệu blockchain, The Graph cho phép truy vấn dữ liệu trên chuỗi trong logic ứng dụng của các nhà phát triển với độ trễ thấp. Khi đó, tốc độ truy vấn sẽ nhanh hơn và dễ dàng hơn.

Bây giờ, kiến ​​trúc DApp của bạn trông giống như sau:

Khả năng mở rộng của DApp

Việc xây dựng DApp trên Ethereum với phí gas cao và full blocks dẫn đến trải nghiệm người dùng rất tệ. Rất may, có một số giải pháp đang được phát triển.

Một giải pháp mở rộng phổ biến là Polygon, một giải pháp L2 mở rộng. Thay vì thực hiện các giao dịch trên blockchain chính, Polygon có các “sidechains” xử lý và thực hiện các giao dịch. Một sidechain là một chuỗi khối thứ cấp giao tiếp với chuỗi chính. Thường xuyên, sidechain gửi tổng hợp các khối gần đây của nó trở lại chuỗi chính.

Tóm lại ý tưởng của của các L2 là: Các giải pháp L2 thực hiện giao dịch ngoài chuỗi, chỉ với dữ liệu giao dịch được lưu trữ trên chuỗi. Điều này cho phép các nhà phát triển mở rộng quy mô blockchain vì họ không phải thực hiện mọi giao dịch trên chuỗi. Điều này cũng làm cho các giao dịch nhanh hơn và rẻ hơn – và chúng vẫn có thể giao tiếp với blockchain Ethereum chính khi cần thiết.

Tổng kết

Trên đây là toàn bộ các thông tin về một cấu trúc cơ bản ứng dụng Web3.0. Anh em yêu thích công nghệ có thể tìm hiểu kỹ hơn về các cấu trúc mở rộng hay các giải pháp trên Web3.0.

Qua cấu trúc cơ bản của Web3.0, anh em có thể nắm được các dự án cung cấp cơ sở hạ tầng đang giải quyết vấn đề gì? Vấn đề đó nằm ở chỗ nào trên Web3? Có thực sự quan trọng không? Và giải pháp đó được thực hiện như thế nào? Ví dụ như hai dự án được nhắc trên cấu trúc Web3.0 như Filecoin và The Graph. Đây là 2 dự án tiềm năng vì có thể giải quyết được các vấn đề của Web3.0 cũng như blockchain Ethereum. Chính vì thế doanh thu và đối tác của 2 dự án trên cũng được mở rộng rất nhiều theo thời gian. Mình nghĩ đây cũng là chìa khoá để có thể tìm các Hidden Gem tiếp theo có thể giải quyết tốt hơn các vấn đề của Web3.0 trong tương lai.

(Bài viết có sử dụng nguồn tư liệu từ Preethi Kasedlydy , cô đã làm việc cho a16z trong giai đoạn 2013-15 và là kỹ sư tại Coinbase từ năm 2016-17. Anh em có thể đọc thêm bản tiếng anh tại đây)

Nếu anh em quan tâm đến các thông tin khác của thị trường và các dự án, hãy đăng ký và tham gia các nhóm, channel của CoinF dưới đây để được thảo luận cùng các admin và nhiều member khác trong cộng đồng:

Youtube Channel

Telegram channel

Telegram Group

Twitter CoinF

Discord

 

Lượt xem: 278
5/5