Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Consider making offers expire

Đang mở
  • Có gì không ổn?
#175 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Lĩnh vực
distributed-systems, fintech-quant

Hướng nghiên cứu

Bắt đầu bằng cách đọc CAP0-0003 và phần thảo luận của issue về hành vi của order-book. So sánh các cách tiếp cận purge và deterministic-expiration được đề xuất, sau đó xác định liệu protocol có cần một semantic và specification đã được quyết định hay không; hiện tại issue không nêu tên các file triển khai, test hoặc tiêu chí hoàn thành cụ thể.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

CAP help wanted needs draft

One of the things we learned with the protocol 10 rollout with changes like CAP0-0003 is that it's becoming increasingly hard to not break certain client business logic that rely on undocumented (something we can improve on for sure) or undefined behavior.

One aspect in particular is on how the order book functions: while the order book can "at any time" cancel or modify outstanding order, the issue is that those events happen so rarely that people may not realize that this is the case.

A simple way to turn the "improbable" into "certainty" (therefore hardening client code), would be to simply move semantics that are closer to how other markets work: force long lasting orders to be recreated at a regular time.

A couple possible approaches to start the discussion.

The purge

There could be a recurrent "purge" of the order book that deletes X% of the orders every T ledgers (both of these would be network parameters).
This approach seems to be close to what we want: non deterministic (due to the random nature) deletion of orders, which forces clients to not rely on any particular behavior of how the order book state is managed.

By having many ledgers between purge events, the "pseudo randomness" that comes with simple things like "ledger hash" is quite strong.

Deterministic expiration

We could also add an expiration time as a network parameter, we would pick something like a week or two as a starting point and offers would just automatically get deleted when they reach their expected life time.

The issue with that approach is that it only partially solves the problem: what if we want in a future upgrade or a future version of the protocol to delete certain offers? If client code relies on certain timing, it won't work.

A nice thing about this solution is that it's basically how standard order books work (be it "good for day" or "good until cancelled" that really means 30 or 60 days for most brokerage firms).

Ngôn ngữ chính
RPC
Star
637
Fork
404
Merge trung bình
1 ngày 17 giờ
Pull request đã merge (30 ngày)
9

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của stellar/stellar-protocol

Tất cả issue của stellar/stellar-protocol

Issue tương tự

Thêm issue về Distributed Systems

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.