I. Ảo tưởng yêu thích của Ngành
Trong một thời gian dài, hiệu suất của một blockchain đã được quảng bá như một con số. TPS đỉnh. Thời gian hoàn tất trong mili giây. Các tiêu chuẩn phòng thí nghiệm dưới điều kiện lý tưởng đã được ghi nhận. Trong khi những con số này hấp dẫn, chúng che giấu một sự thật đáng kinh ngạc: thông lượng không phải là thước đo của kiến trúc hệ thống.
Tốc độ không phải là một đức tính khi ở một mình. Nó là một bài kiểm tra căng thẳng.
Khi nhìn vào thời gian chạy tuần tự, những điểm yếu cấu trúc được che giấu khá tốt. Các giao dịch xếp hàng. Các khối được lấp đầy theo thứ tự. Mỗi tương tác đều đi qua cùng một lối xử lý hẹp. Và vì mọi thứ đều được tuần tự hóa theo mặc định, mỗi ứng dụng dường như đều phải chịu cùng một lực cản hệ thống. Độ trễ môi trường là một thuộc tính được chấp nhận của môi trường hơn là một tín hiệu chẩn đoán.
Khi người dùng bị giữ trong bóng tối vì các nhà phát triển không nhìn thấy rõ, họ không thể thấy vấn đề là gì. Mạng có bị bão hòa không? Hợp đồng có được thiết kế kém không? Một đối tượng trạng thái chia sẻ có trở thành một điểm nghẽn ẩn không? Mọi thứ được xử lý lần lượt theo thứ tự, và các lỗi kiến trúc hệ thống bị chôn vùi bằng cách phân phối độ chậm đều trên toàn hệ thống.
Tắc nghẽn là sự ngụy trang, trong những tình huống này.
Bây giờ, hãy tưởng tượng áp dụng cùng một chương trình trên một Layer 1 dựa trên SVM như Fogo - sự ngụy trang biến mất - các giao dịch không còn xếp hàng ngẫu nhiên nữa vì chúng thực thi, độc lập. Điều này có nghĩa là sẽ không có xung đột giả định trừ khi chúng được tuyên bố thông qua một trạng thái có thể ghi chia sẻ.
Các mũi tên song song di chuyển sạch sẽ qua hệ thống - tức là, cho đến khi chúng giao nhau với một tài khoản duy nhất.
Tại thời điểm đó, chuỗi quay lại thành tuần tự không phải vì chuỗi chậm, mà vì kiến trúc đã yêu cầu một khóa.
Điểm nghẽn không còn trừu tượng, mà là rõ ràng.
Và tốc độ, không làm phát sinh ma sát, mà lộ ra nó.
II. Trạng thái như một bề mặt đồng thời
Trong một thời gian chạy song song, trạng thái không phải là lưu trữ thụ động. Nó là chính sách đồng thời.
Mỗi tài khoản có thể ghi đại diện cho một ranh giới khóa. Khi một giao dịch tuyên bố rằng nó dự định thay đổi một tài khoản, thời gian chạy phải đảm bảo quyền truy cập độc quyền. Nếu hai giao dịch cố gắng sửa đổi cùng một tài khoản đồng thời, một trong số đó phải chờ. Đây không phải là sự không hiệu quả, mà là sự chính xác.
Hệ quả kiến trúc là nghiêm trọng: mỗi đối tượng có thể ghi chia sẻ trở thành một bề mặt tuần tự hóa. Một bộ đếm toàn cầu được cập nhật trên mỗi giao dịch, một số liệu toàn bộ giao thức được tính toán lại theo từng tương tác. Có một tài khoản bể thanh khoản cho tất cả các giao dịch hoán đổi. Khi lưu lượng thấp, những lựa chọn thiết kế này có vẻ an toàn hợp lý. Khi lưu lượng cao, chúng đại diện cho giới hạn trên của khả năng mở rộng.
Để thực thi song song hoạt động, các sửa đổi xảy ra phải độc lập.
Các sửa đổi trạng thái tách biệt có thể được thực hiện bởi người dùng cho các tài khoản cá nhân, các bể phân chia, hoặc các sổ lệnh riêng biệt. Trong những kịch bản này, thời gian chạy của hệ thống có thể lên lịch sửa đổi các trạng thái đó mà không can thiệp vào nhau. Điều này tự nhiên làm tăng thông lượng.
Khi mọi hoạt động được hướng đến một trạng thái có thể thay đổi, hệ thống bị buộc phải xử lý tuần tự tại trạng thái đó. Bất kể có bao nhiêu lõi hiện diện hay độ trễ thấp đến đâu, trạng thái chia sẻ trở thành một điểm nghẽn.
Đây là cốt lõi của vấn đề mà nhu cầu về sự song song tạo ra.
Trong một hệ thống tuần tự, một trạng thái toàn cầu là hữu ích. Trong các hệ thống song song, một trạng thái toàn cầu là một nguồn tài nguyên đắt đỏ.
Khi thiết kế cho sự đồng thời, cần phải phân tích từng biến:
Liệu giá trị này có thực sự cần được thay đổi đồng bộ không?
Liệu nó có thể được phân chia theo người dùng, thị trường, hoặc thời kỳ không?
Liệu báo cáo có thể tách biệt khỏi sự chính xác không?
Liệu các đường đi thực thi quan trọng có thể không có phân tích không?
Đây không phải là tối ưu hóa vi mô — đây là các cam kết cấu trúc.
Một khi hệ thống đã được triển khai, sự song song không thể được thêm vào như một suy nghĩ sau. Nó phải được xây dựng vào thiết kế của topo trạng thái ngay từ đầu.
III. Động cơ và Khung
Các động cơ hiệu suất cao tạo ra năng lượng. Điều chỉnh vị trí của động cơ sẽ không thay đổi khả năng đó.
Đặt động cơ vào một khung được căn chỉnh tốt. Với hình học đúng và một sự phân phối tốt của tất cả các lực, khung cũng sẽ hoạt động tốt và gia tốc sẽ mượt mà. Khung và động cơ sẽ hoạt động đối xứng với nhau và việc chuyển đổi năng lượng thành chuyển động sẽ không bị lãng phí.
Nhưng nếu động cơ đó được đặt vào một khung không được căn chỉnh với sự chú ý vào các khớp yếu, các con đường thấp sẽ thay đổi và hiệu suất cũng sẽ thay đổi. Sự rung động sẽ được khuếch đại. Các thành phần sẽ bị căng thẳng. Các vết nứt sẽ được tạo ra bởi áp lực. Động cơ không thất bại. Cấu trúc không thể chịu đựng đầu ra.
Đây là cách các thời gian chạy song song hoạt động.
Một động cơ SVM như Fogo cung cấp độ trễ thấp và thông lượng cao với thực thi đồng thời. Nó sẽ không giảm hiệu suất của nó để phù hợp với các lỗi trong kiến trúc. Động cơ sẽ không bị khóa vì sự tắc nghẽn chung.
Điều này sẽ làm tăng các lỗi của cấu trúc.
Nếu một hợp đồng chỉ đạo tất cả các ghi vào một tài khoản duy nhất, sẽ có sự tuần tự hóa. Một giao thức phụ thuộc vào một cập nhật toàn cầu đồng bộ sẽ bị trì hoãn tại các điểm tranh chấp dự kiến. Thời gian chạy sẽ không giảm thiểu các kết quả. Nó sẽ rõ ràng điều gì sẽ xảy ra chính xác.
Câu của bạn đã gây nhầm lẫn. Tôi đã thay đổi thứ tự của một số từ nhưng tôi không thay đổi ý nghĩa.
IV. Thứ năm. Một trường hợp cho thiết kế tích hợp.
Mục tiêu không phải là trừng phạt. Mục tiêu là đo lường.
Khi được tích hợp với các giới hạn theo chiều dọc, một chuỗi tuần tự cố định có thể che giấu những thiếu sót trong một thời gian dài. Một chuỗi song song nhanh thì không thể.
Khi X-quang đầu tiên xuất hiện, trách nhiệm của kiến trúc sư không còn có thể bị tránh.
Kỷ luật cho việc giữ song song.
Thiết kế cho thực thi song song đòi hỏi trật tự ở cấp độ trạng thái:
Cách ly mặc định của các trạng thái người dùng. Độc lập như một trạng thái tồn tại là một cơ sở, không phải là một điều chỉnh sau đó.
Các hệ thống chia sẻ nên được chia nhỏ. Người dùng của các hệ thống chia sẻ như thị trường, bể hoặc sổ lệnh nên được tách ra khi có thể để giảm bề mặt tranh chấp.
Giữ sự chính xác và báo cáo tách biệt. Các bất biến trên chuỗi mà phải đúng nên đồng bộ, trong khi phân tích và số liệu có thể không đồng bộ.
Việc ghi toàn cầu nên được tối thiểu hóa. Mỗi tài khoản có thể ghi chia sẻ nên được coi là một nguồn tài nguyên khan hiếm.
Sự tranh chấp nên được mô hình hóa một cách rõ ràng. Nếu một người dùng tuần tự hóa, thiết kế để bù đắp chi phí của sự chứa đựng trong khi giả định không có tuần tự hóa.
Mục tiêu không phải là loại bỏ hoàn toàn các trạng thái và hệ thống chia sẻ. Các bất biến quan trọng yêu cầu một mức độ phối hợp nào đó. Mục tiêu nên là sự tuần tự hóa có chủ ý và tối thiểu.
Sự rõ ràng cấu trúc được thưởng bằng sự song song.
V. Điều gì Tốc độ Cuối cùng Tiết lộ
Cơ sở hạ tầng nhanh không phải là một đảm bảo cho các ứng dụng. Điều nó đảm bảo là sự cởi mở. *Khi các thời gian chạy song song đạt đến các giới hạn hiệu suất, thường không phải là một bí ẩn tại sao. Đây là các kết quả trực tiếp từ trạng thái có thể ghi chia sẻ, các điểm tập trung thay đổi, và các lựa chọn kiến trúc được thực hiện sớm và không được xem xét.
Trong nghĩa đó, tốc độ không phải là một tính năng marketing, mà là một X-quang.
Nó loại bỏ sự mờ ảo từng che giấu sự tranh chấp. Nó phân biệt các giới hạn mạng khỏi các lỗi thiết kế ứng dụng. Nó làm cho các ranh giới khóa trở nên rõ ràng.
Và một khi đã được nhìn thấy, chúng có thể được thiết kế lại.
Tương lai của các blockchain hiệu suất cao sẽ không chỉ được xác định bởi các thời gian chạy nhanh hơn. Nó sẽ được xác định bởi việc các nhà phát triển tiếp thu bài học mà những thời gian chạy đó thực thi: độc lập là khả năng mở rộng.
Thông lượng không được thừa hưởng từ chuỗi. Nó được kiếm được thông qua kiến trúc.
\u003cm-177/\u003e \u003ct-179/\u003e \u003cc-181/\u003e
