One feature, traced from the research question through to the shipped protocol and the specification that documents it. This is what a piece of work looks like when I own it.
Why uncapped competition wastes the network, what capping reservations fixes, and an adversarial analysis of six attacker classes.
research#190 · mergedSix numbered workstreams, each split across the contracts repo and the client repo, with dependencies made explicit and estimates attached.
pm#45 · 12 Jun 2024Solidity contract changes and Nim client changes landed in step, each pair kept independently reviewable.
contracts-eth + nim · Sep–Oct 2024Filling Slots section of the marketplace spec updated, so the mechanism is described where implementers will look for it.
spec#9 · mergeddesign → plan → build → document
Broken down by feature, each subtask affects a different repo. Note that some features were not shipped: the expanding window and the dispersal parameter in particular. These were seen as necessary for mainnet, but not showstoppers to deliver the slot reservations functionality for testnet.
reserveSlot and canReserveSlotexpansionRate parameter to support contract changesStorageRequest and needs to be supported in the Codex client.SaleReserving stateSaleReserving to the sales state machine that reserves a slot before attempting to fill the slot. This should be the first state after SalePreparingseen flag refactorseenNoAvailability from seenNotEligible so only one pauses the queueSlotReservationsFull eventconfig._MAX_RESERVATIONS, a SlotReservationsFull event is emitted with the RequestId and slotIndex of the slot.SlotRervationsFull contract event. Subscribes to the SlotReservationsFull event in the sales module. When emitted, the slot is removed from the slot queue.reserveSlot logic for expanding window_reservations contains the sender address for the slot.The public design was created first. The mechanisms were discussed and ultimately a final design was distilled from these discussions. It's always easier to modify designs than implementation. Ideas that were rejected were documented alongside the final design.
Clearly planned execution. Implementation was split into workstreams with contract and client work further split into distinct tasks. This type of planning is transparent, easier to delegate and easily planned for, while being able to easily identify features that can be put on hold to make a deadline.
Scope was reduced when needed. Three of eleven items were marked on hold, with the estimate revised once the reservation work was done. The expanding window is a complex feature to implement in a contract, and it solves problems that exist only at scale, so putting it on hold allowed us to ship the testnet first, with work continuing on this feature later.
Documentation, not forgotten. The public marketplace spec was updated with the design details of the slot reservations, so that other contributors and future team members can reference it.
← Back Recoverability analysis → Read the design → Gas analysis →