Giới thiệu

Trong thế giới Web3, tự động hóa thường gặp khó khăn do nhiều yếu tố như thời gian chờ quá lâu, chi phí gas tăng đột biến, và các giới hạn về tần suất gọi API. Nếu bạn đã từng phát triển một ứng dụng phức tạp trong Web3, chắc hẳn bạn đã trải qua những rắc rối này: vòng lặp kiểm tra, retry, logic chuyển đổi và một công việc giám sát không bao giờ ngừng nghỉ. Kwala chính là giải pháp giúp bạn loại bỏ hoàn toàn những vấn đề này.

Kwala: Giải pháp tự động hóa sự kiện

Kwala là một lớp thực thi dựa trên sự kiện, hoạt động tại mức độ giao thức, lắng nghe các sự kiện và chuyển hướng chúng vào các quy trình YAML có thể định nghĩa. Điều này cho phép các ứng dụng hoạt động một cách đáng tin cậy trên mạng Kalp mà không cần phải lo lắng về việc kiểm tra định kỳ, quản lý RPC hay giám sát hạ tầng.

Tại sao các lỗi RPC gây khó khăn cho tự động hóa

• Polling: Phương pháp này vốn đã không ổn định. Khi bạn thực hiện polling một RPC, bạn đang phụ thuộc vào ba yếu tố: khả năng truy cập, độ trễ và sự nhất quán trong việc lập chỉ mục.
• Giới hạn RPC: Các điểm cuối RPC và giới hạn tần suất từ nhà cung cấp có thể gây ra sự cố.
• Tắc nghẽn và thay đổi chi phí gas: Những yếu tố này có thể làm thay đổi điều kiện thành công trong quá trình thực hiện.
• Logic chuyển đổi: Cần thiết nhưng cũng trở thành một phần hạ tầng phức tạp.

Theo nghiên cứu, dịch vụ RPC là một bề mặt tấn công hấp dẫn và là điểm thất bại duy nhất cho các dApp. Thực tế cho thấy các nhà cung cấp RPC trung tâm có thể trở thành điểm nghẽn quan trọng.

Cách Kwala hoạt động

Kwala hoạt động bằng cách chạy một lớp tự động hóa có quyền truy cập trên mạng Kalp, nơi các node quan sát hoạt động ở mức khối trong thời gian thực. Khi một hợp đồng phát sinh sự kiện, mạng sẽ chuyển hướng sự kiện đó đến động cơ thực thi và kích hoạt quy trình YAML của bạn. Điều này có nghĩa là logic của bạn sẽ hoạt động gần với thời điểm hoàn tất khối, thay vì theo một chu kỳ polling tùy ý.

Kết quả chính:

• Xử lý sự kiện gần như ngay lập tức với độ chi tiết ở mức khối.
• Không cần quản lý RPC cho từng chuỗi trong stack của bạn.
• Logic chuyển đổi được tích hợp sẵn và có tính xác định.
• Bản ghi thực thi có thể kiểm toán trên chuỗi cho mục đích kiểm tra và tuân thủ.

So sánh giữa Polling và Thực thi Dựa trên Sự kiện

Ví dụ thực tế với YAML: Trường hợp VotePassed

Giả sử bạn muốn một quy trình tự động phản ứng khi có một cuộc bỏ phiếu trong DAO và phát hành quỹ nếu đề xuất được thông qua. Với Kwala, bạn chỉ cần viết một tệp nhỏ và triển khai nó:

trigger:
  contract_event:
    contract: "0xDAO"
    event: "VotePassed"
actions:
  - call_contract:
      function: "releaseFunds"
      contract: "0xTreasury"

Không cần vòng lặp setInterval, không cần polling web3.js, không cần các lần thử lại dễ bị hỏng. Một sự kiện sẽ kích hoạt mạng Kalp, thực hiện quy trình, thực hiện hành động, và ghi lại kết quả trên chuỗi để kiểm toán.

Tại sao quy trình có thể kiểm chứng là quan trọng

• Độ trễ khớp với chuỗi: Tự động hóa của bạn nên phản ánh thời điểm hoàn tất của chuỗi, không phải lịch trình polling.
• Khả năng phục hồi mà không cần kỹ thuật dư thừa: Ngừng xây dựng các hệ thống chuyển đổi tùy chỉnh; hãy dựa vào thực thi có tính xác định.
• Thực thi có thể kiểm chứng: Mỗi lần thực hiện trở thành một tác phẩm ký, có thể phát lại mà bạn có thể kiểm tra trong các cuộc kiểm tra sau đó.
• Đa chuỗi mà không cần nhiều hạ tầng node: Cấu hình mục tiêu chuỗi trong YAML thay vì cung cấp các đội quân node riêng biệt.

Tất cả những điều này giúp giảm tải cognitive và bảo trì cho các đội ngũ nên tập trung vào việc phát triển logic sản phẩm, không phải chữa cháy hạ tầng.

An toàn vận hành: ít bất ngờ hơn, rõ ràng hơn

Giới hạn tần suất RPC, giảm tốc từ nhà cung cấp và các sự cố không mong muốn thường dẫn đến nợ vận hành chồng chéo, bao gồm các giao dịch trùng lặp, sự kiện bị bỏ qua, và các lỗi im lặng chỉ được phát hiện khi người dùng báo cáo. Các thực hành tốt nhất về bảo mật RPC và quy tắc truy cập giúp giảm thiểu rủi ro, nhưng không loại bỏ hoàn toàn việc bảo trì và xử lý các trường hợp ngoại lệ. Di chuyển logic thực thi gần hơn đến chuỗi và vào một lớp thực thi có thể kiểm toán giúp giảm số lượng thành phần mà bạn phải vận hành và lý giải.

Bước tiếp theo: Đừng coi RPC như một sản phẩm

Nếu tự động hóa của bạn dựa trên polling, bạn đang mang một gánh nặng hạ tầng vĩnh viễn. Hãy viết các quy trình hoạt động song hành với chuỗi thay vì quanh nó. Diễn đạt logic của bạn bằng YAML, thử nghiệm trong Kwala Playground, và triển khai trên mạng Kalp. Tự động hóa của bạn trở nên có tính xác định, có thể kiểm toán và phục hồi, giúp đội ngũ của bạn tập trung vào hành vi của sản phẩm thay vì duy trì các cuộc gọi RPC.