tôi đã dành cả buổi sáng để xem xét một giao dịch duskevm thực sự đi qua hệ thống như thế nào và thành thật mà nói? 😂 tôi cứ nghĩ một khi nó đã xuất hiện trong một block thì mình coi như xong rồi, ai ngờ không phải vậy.
vậy thì duskevm là lớp tương thích EVM trên dusk, nghĩa là bạn viết solidity, dùng các ví EVM thông thường và các công cụ chuẩn như foundry hoặc hardhat, và trả gas bằng dusk. nhưng giao dịch đó không tự “sống và chết” chỉ trong duskevm. nó đi qua một vòng đời kiểu rollup. đầu tiên nó được gửi tới duskevm sequencer, sau đó được đưa vào một block L2 tương đối nhanh. sau đó một batcher sẽ công bố dữ liệu giao dịch sang duskds, là lớp settlement và data availability thực sự của dusks. các state commitments và fault proofs là thứ kết nối trạng thái kết quả đó quay trở lại duskds, để nó được coi là đã được settle, chứ không chỉ “nằm đâu đó” trong một block L2 chờ đợi.
điều tôi cứ quay lại mãi là một dòng trong tài liệu nhấn mạnh việc inclusion và settlement là hai giai đoạn thật sự khác nhau. các app chuyển giá trị giữa duskevm và dusk l1 nên kiểm tra trạng thái protocol hoặc trạng thái ví thay vì chỉ giả định rằng mọi thứ đã final vì đã trôi qua một khoảng thời gian. đây không phải chỉ là một chi tiết kỹ thuật.
tôi vẫn chưa tìm thấy chỗ nào nói rõ khoảng cách đó thường dài bao lâu trong thực tế. inclusion nhanh chắc chắn không đồng nghĩa với settlement tức thì, nhưng tôi không biết người ta nên chờ trong khung thời gian bao lâu.
dù sao thì lựa chọn thiết kế đó vẫn có ý nghĩa với tôi. thay vì xây một chuỗi EVM hoàn toàn tách biệt, lơ lửng một mình, duskevm được neo chặt vào duskds để settlement và data availability, nên bạn vẫn có đầy đủ bộ công cụ solidity mà không mất đi các đảm bảo cốt lõi của lớp nền về finality.
thành thật mà nói, tôi không biết khoảng trống giữa inclusion và settlement có đủ nhỏ để bỏ qua trong dùng hằng ngày không, hay các builder cần chủ động tính toán/để ý đến??
🤔
#dusk @Dusk $DUSK
vậy thì duskevm là lớp tương thích EVM trên dusk, nghĩa là bạn viết solidity, dùng các ví EVM thông thường và các công cụ chuẩn như foundry hoặc hardhat, và trả gas bằng dusk. nhưng giao dịch đó không tự “sống và chết” chỉ trong duskevm. nó đi qua một vòng đời kiểu rollup. đầu tiên nó được gửi tới duskevm sequencer, sau đó được đưa vào một block L2 tương đối nhanh. sau đó một batcher sẽ công bố dữ liệu giao dịch sang duskds, là lớp settlement và data availability thực sự của dusks. các state commitments và fault proofs là thứ kết nối trạng thái kết quả đó quay trở lại duskds, để nó được coi là đã được settle, chứ không chỉ “nằm đâu đó” trong một block L2 chờ đợi.
điều tôi cứ quay lại mãi là một dòng trong tài liệu nhấn mạnh việc inclusion và settlement là hai giai đoạn thật sự khác nhau. các app chuyển giá trị giữa duskevm và dusk l1 nên kiểm tra trạng thái protocol hoặc trạng thái ví thay vì chỉ giả định rằng mọi thứ đã final vì đã trôi qua một khoảng thời gian. đây không phải chỉ là một chi tiết kỹ thuật.
tôi vẫn chưa tìm thấy chỗ nào nói rõ khoảng cách đó thường dài bao lâu trong thực tế. inclusion nhanh chắc chắn không đồng nghĩa với settlement tức thì, nhưng tôi không biết người ta nên chờ trong khung thời gian bao lâu.
dù sao thì lựa chọn thiết kế đó vẫn có ý nghĩa với tôi. thay vì xây một chuỗi EVM hoàn toàn tách biệt, lơ lửng một mình, duskevm được neo chặt vào duskds để settlement và data availability, nên bạn vẫn có đầy đủ bộ công cụ solidity mà không mất đi các đảm bảo cốt lõi của lớp nền về finality.
thành thật mà nói, tôi không biết khoảng trống giữa inclusion và settlement có đủ nhỏ để bỏ qua trong dùng hằng ngày không, hay các builder cần chủ động tính toán/để ý đến??
🤔
#dusk @Dusk $DUSK