Giới thiệu
Smart contract đã tạo điều kiện cho một thế hệ ứng dụng onchain mới. Chúng cho phép khả năng kết hợp, tự động hóa và thực thi minh bạch trong các môi trường dùng chung.
Nhưng khi một sản phẩm phát triển, những giới hạn mới sẽ xuất hiện mà không thể giải quyết chỉ bằng cách thêm nhiều hợp đồng hay thêm nhiều lớp trừu tượng hơn.
Ở một giai đoạn nhất định, bài toán không còn là viết logic nữa mà chuyển sang kiểm soát môi trường nơi logic đó chạy. Đó là thời điểm nhiều đội bắt đầu xem appchains và các L1 chủ quyền như một nhu cầu thực tiễn, chứ không phải một lựa chọn mang tính ý thức hệ.
Văn bản này thảo luận vì sao bước chuyển dịch đó xảy ra, những giới hạn nào xuất hiện trong các kiến trúc dùng chung và sự chủ quyền ở cấp độ giao thức sẽ thay đổi tập hợp các quyết định mà builder có thể lựa chọn như thế nào.
Giới hạn cấu trúc của blockspace dùng chung
Các nền tảng dùng chung hoạt động tốt miễn là yêu cầu của sản phẩm vẫn ở mức chung chung. Nhưng khi ứng dụng bắt đầu phụ thuộc vào các bảo đảm cụ thể, một số ma sát sẽ trở nên lặp đi lặp lại.
Trong số những lựa chọn phổ biến nhất có:
chi phí thực thi thay đổi theo nhu cầu của mạng
cạnh tranh blockspace với các ứng dụng không liên quan đến sản phẩm
phụ thuộc lịch trình bên ngoài cho các bản nâng cấp và thay đổi mang tính cấu trúc
các quy tắc quan trọng chỉ được triển khai trong hợp đồng, bị phân mảnh hoặc khó áp đặt một cách nhất quán
Ở giai đoạn này, rủi ro không chỉ mang tính kỹ thuật. Nó ảnh hưởng đến khả năng dự đoán, UX và, trong một số trường hợp, đến tính khả thi của chính sản phẩm.
Giới hạn không nằm ở chính các smart contract, mà nằm ở chỗ chúng hoạt động trong một môi trường mà đội ngũ không kiểm soát.
Khi quyền kiểm soát cần đi lên cấp độ giao thức
Một số yêu cầu rất khó diễn đạt ngoài giao thức. Không phải vì chúng phức tạp, mà vì chúng đòi hỏi sự nhất quán và enforcement ở cấp độ gốc.
Khi kiểm soát hành vi của chuỗi, đội ngũ bắt đầu quyết định:
việc thực thi diễn ra như thế nào
những quy tắc nào được áp đặt cho tất cả các giao dịch
cách hoạt động của phí, ưu đãi và mô hình gas
cách nâng cấp và thay đổi được áp dụng theo thời gian
Những quyết định này không còn là lựa chọn cục bộ của hợp đồng nữa, mà trở thành thuộc tính của chính mạng lưới.
Tác động thực tế là thu hẹp khoảng cách giữa điều mà sản phẩm hứa hẹn và điều mà hạ tầng có thể bảo đảm.
Ví dụ 1: các giao thức tín dụng và thực thi dự đoán được
Các giao thức tín dụng xử lý thời hạn, thanh toán và rủi ro. Những thay đổi nhỏ trong thực thi có thể tạo ra tác động không tương xứng.
Trong môi trường dùng chung, tắc nghẽn và các đỉnh chi phí tạo ra bất định. Việc thanh toán bị trễ, phí biến động và các quy tắc quan trọng phụ thuộc vào các hợp đồng được cô lập.
Trong một L1 chủ quyền, pipeline thực thi là dành riêng. Các quy tắc xác thực và thanh toán có thể được tích hợp sẵn. Chi phí và thời gian trở nên dự đoán được.
Với kiểu sản phẩm này, tính dự đoán không phải là tối ưu hóa. Đó là yêu cầu vận hành.
Ví dụ 2: RWAs và quản trị cần phải tiến hóa
Các ứng dụng gắn với tài sản của thế giới thực hiếm khi đứng yên. Chúng đòi hỏi các điều chỉnh thường xuyên về quy tắc, tham số và quy trình quản trị.
Một mô hình phổ biến là bắt đầu với các cấu trúc gọn hơn để lặp nhanh và, khi sản phẩm trưởng thành, mở rộng mức độ tham gia và phi tập trung hóa.
Khi quản trị và nâng cấp được xử lý ở cấp độ giao thức, sự chuyển dịch này trở nên đơn giản hơn. Các thay đổi không còn là sự kiện ngoại lệ nữa mà trở thành một phần của quá trình tiến hóa thông thường của hệ thống.
Điều này giảm rủi ro vận hành và cải thiện khả năng thích ứng theo thời gian.
Ví dụ 3: ứng dụng tiêu dùng và các mô hình gas linh hoạt
Trong các sản phẩm hướng đến người dùng cuối, ma sát về UX thường là nút thắt chính. Token không quen thuộc, chi phí khó dự đoán và các bước bổ sung trong onboarding ảnh hưởng đến mức độ chấp nhận.
Các mô hình linh hoạt hơn cho phép:
chọn token được dùng cho các khoản phí
trợ cấp cho các giao dịch ban đầu
tạo các luồng để người dùng không phải làm việc trực tiếp với gas
Loại quyết định này không mang tính thẩm mỹ. Nó xác định ai có thể sử dụng sản phẩm và với tần suất như thế nào.
Khi các quy tắc đó được xử lý ở cấp độ giao thức, đội ngũ sẽ có tự do để thiết kế các trải nghiệm gần hơn với kỳ vọng của người dùng phổ thông.
Vì sao L2s không phải lúc nào cũng giải quyết được
L2s là một giải pháp tuyệt vời khi kiểm soát sâu không phải là ưu tiên. Chúng thừa hưởng bảo mật và tăng tốc việc ra mắt.
Tuy nhiên, có những yêu cầu xuất hiện sớm trong các sản phẩm chuyên biệt hơn:
logic thực thi vượt ra ngoài những gì các hợp đồng có thể áp đặt
các thị trường gas riêng cho ứng dụng
nâng cấp và quản trị không thể phụ thuộc vào phối hợp bên ngoài
hiệu năng dự đoán được mà không phải tranh giành quyền thực thi
Khi các yếu tố đó trở thành trọng tâm, câu hỏi sẽ thay đổi. Không còn là mở rộng các hợp đồng nữa, mà là kiểm soát chính nền tảng nơi sản phẩm vận hành.
Kết luận
Việc di chuyển sang một L1 chủ quyền không xảy ra vì sở thích kiến trúc trừu tượng. Nó xuất hiện khi các giới hạn của môi trường dùng chung bắt đầu ảnh hưởng đến sản phẩm.
Điểm cốt lõi không phải là loại bỏ các lớp trừu tượng, mà là phân phối lại trách nhiệm. Khi tách quyền kiểm soát của giao thức khỏi phần vận hành hạ tầng, các đội có thể duy trì tính tự chủ mà không phải gánh nặng lịch sử vận hành một mạng từ con số không.
Đối với các builder, quyết định này đi qua một câu hỏi vừa đơn giản vừa khó:
trong sản phẩm của bạn, phần nào còn có thể tồn tại trong các hợp đồng và phần nào đã cần quyền kiểm soát chuỗi của chính mình?
Trả lời điều này một cách trung thực thường cho thấy bước tiếp theo về mặt kiến trúc.
Tham khảo kỹ thuật
Văn bản này dựa trên các khái niệm về custom hóa appchains và kiểm soát ở cấp độ giao thức do Tanssi Network trình bày.
Bài viết chính thức của @Tanssi
Tùy chỉnh Your Appchain (L1) - https://www.tanssi.network/post/customizing-your-l1