Tôi suýt bỏ cuộc khi làm mới số dư của mình hai lần trước khi hiểu chính xác là mình đang chờ điều gì.
Hoàng hôn không coi một giao dịch được “cầu nối” như một khoảnh khắc đơn lẻ. Trước hết, sequencer sẽ đưa giao dịch vào một khối L2; sau đó batcher sẽ công bố dữ liệu đó trở lại DuskDS, và chỉ khi các cam kết trạng thái cùng với các bằng chứng lỗi neo vào đó thì việc chuyển tiền mới thực sự được thanh toán.
Đây là phần khiến cách đọc của tôi về vấn đề này thay đổi: hầu hết các rollup EVM đều bắt bạn phải ngồi qua một khoảng “thử thách” xấp xỉ bảy ngày trước khi việc rút tiền thật sự được coi là cuối cùng, vì ai đó cần có thời gian để tranh chấp một trạng thái sai. DuskEVM thì thanh toán thẳng lên DuskDS, không có cửa sổ lỗi bảy ngày. Vì vậy, khoảng cách giữa việc được đưa vào (inclusion) và việc được thanh toán (settlement) không phải là vài ngày, mà là thứ bạn có thể “chớp mắt là qua”. Đó là một lựa chọn thiết kế thật sự, chứ không chỉ là phần kỹ thuật vận hành.
Nó gần như làm mọi thứ tệ hơn theo một cách nào đó. Nếu độ trễ dài, bạn sẽ mong phải chờ và lên kế hoạch dựa trên nó. Vì nó nhanh, rất dễ nhầm “được đưa vào” với “đã cuối cùng” và không bao giờ nhận ra rằng có hai yêu cầu tách biệt đang được đưa ra.
Tôi thích ở chỗ giao thức vẫn giữ cho các yêu cầu đó là khác nhau, ngay cả khi khoảng cách giữa chúng nhỏ đến mức có thể bỏ qua.
Vậy việc thu gọn cửa sổ lỗi xuống gần như tức thời có phải là một nâng cấp nâng cao khả năng chịu lỗi một cách thực sự so với mô hình rollup tiêu chuẩn, hay việc loại bỏ thời gian chờ dài chỉ khiến người ta mất đi “tín hiệu” để cẩn thận?
#dusk @Dusk $DUSK $PENGU $TUT
Hoàng hôn không coi một giao dịch được “cầu nối” như một khoảnh khắc đơn lẻ. Trước hết, sequencer sẽ đưa giao dịch vào một khối L2; sau đó batcher sẽ công bố dữ liệu đó trở lại DuskDS, và chỉ khi các cam kết trạng thái cùng với các bằng chứng lỗi neo vào đó thì việc chuyển tiền mới thực sự được thanh toán.
Đây là phần khiến cách đọc của tôi về vấn đề này thay đổi: hầu hết các rollup EVM đều bắt bạn phải ngồi qua một khoảng “thử thách” xấp xỉ bảy ngày trước khi việc rút tiền thật sự được coi là cuối cùng, vì ai đó cần có thời gian để tranh chấp một trạng thái sai. DuskEVM thì thanh toán thẳng lên DuskDS, không có cửa sổ lỗi bảy ngày. Vì vậy, khoảng cách giữa việc được đưa vào (inclusion) và việc được thanh toán (settlement) không phải là vài ngày, mà là thứ bạn có thể “chớp mắt là qua”. Đó là một lựa chọn thiết kế thật sự, chứ không chỉ là phần kỹ thuật vận hành.
Nó gần như làm mọi thứ tệ hơn theo một cách nào đó. Nếu độ trễ dài, bạn sẽ mong phải chờ và lên kế hoạch dựa trên nó. Vì nó nhanh, rất dễ nhầm “được đưa vào” với “đã cuối cùng” và không bao giờ nhận ra rằng có hai yêu cầu tách biệt đang được đưa ra.
Tôi thích ở chỗ giao thức vẫn giữ cho các yêu cầu đó là khác nhau, ngay cả khi khoảng cách giữa chúng nhỏ đến mức có thể bỏ qua.
Vậy việc thu gọn cửa sổ lỗi xuống gần như tức thời có phải là một nâng cấp nâng cao khả năng chịu lỗi một cách thực sự so với mô hình rollup tiêu chuẩn, hay việc loại bỏ thời gian chờ dài chỉ khiến người ta mất đi “tín hiệu” để cẩn thận?
#dusk @Dusk $DUSK $PENGU $TUT
