You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

87 lines
3.6 KiB

Redo coordinator structure, connect API to node - API: - Modify the constructor so that hardcoded rollup constants don't need to be passed (introduce a `Config` and use `configAPI` internally) - Common: - Update rollup constants with proper *big.Int when required - Add BidCoordinator and Slot structs used by the HistoryDB and Synchronizer. - Add helper methods to AuctionConstants - AuctionVariables: Add column `DefaultSlotSetBidSlotNum` (in the SQL table: `default_slot_set_bid_slot_num`), which indicates at which slotNum does the `DefaultSlotSetBid` specified starts applying. - Config: - Move coordinator exclusive configuration from the node config to the coordinator config - Coordinator: - Reorganize the code towards having the goroutines started and stopped from the coordinator itself instead of the node. - Remove all stop and stopped channels, and use context.Context and sync.WaitGroup instead. - Remove BatchInfo setters and assing variables directly - In ServerProof and ServerProofPool use context instead stop channel. - Use message passing to notify the coordinator about sync updates and reorgs - Introduce the Pipeline, which can be started and stopped by the Coordinator - Introduce the TxManager, which manages ethereum transactions (the TxManager is also in charge of making the forge call to the rollup smart contract). The TxManager keeps ethereum transactions and: 1. Waits for the transaction to be accepted 2. Waits for the transaction to be confirmed for N blocks - In forge logic, first prepare a batch and then wait for an available server proof to have all work ready once the proof server is ready. - Remove the `isForgeSequence` method which was querying the smart contract, and instead use notifications sent by the Synchronizer to figure out if it's forging time. - Update test (which is a minimal test to manually see if the coordinator starts) - HistoryDB: - Add method to get the number of batches in a slot (used to detect when a slot has passed the bid winner forging deadline) - Add method to get the best bid and associated coordinator of a slot (used to detect the forgerAddress that can forge the slot) - General: - Rename some instances of `currentBlock` to `lastBlock` to be more clear. - Node: - Connect the API to the node and call the methods to update cached state when the sync advances blocks. - Call methods to update Coordinator state when the sync advances blocks and finds reorgs. - Synchronizer: - Add Auction field in the Stats, which contain the current slot with info about highest bidder and other related info required to know who can forge in the current block. - Better organization of cached state: - On Sync, update the internal cached state - On Init or Reorg, load the state from HistoryDB into the internal cached state.
4 years ago
Redo coordinator structure, connect API to node - API: - Modify the constructor so that hardcoded rollup constants don't need to be passed (introduce a `Config` and use `configAPI` internally) - Common: - Update rollup constants with proper *big.Int when required - Add BidCoordinator and Slot structs used by the HistoryDB and Synchronizer. - Add helper methods to AuctionConstants - AuctionVariables: Add column `DefaultSlotSetBidSlotNum` (in the SQL table: `default_slot_set_bid_slot_num`), which indicates at which slotNum does the `DefaultSlotSetBid` specified starts applying. - Config: - Move coordinator exclusive configuration from the node config to the coordinator config - Coordinator: - Reorganize the code towards having the goroutines started and stopped from the coordinator itself instead of the node. - Remove all stop and stopped channels, and use context.Context and sync.WaitGroup instead. - Remove BatchInfo setters and assing variables directly - In ServerProof and ServerProofPool use context instead stop channel. - Use message passing to notify the coordinator about sync updates and reorgs - Introduce the Pipeline, which can be started and stopped by the Coordinator - Introduce the TxManager, which manages ethereum transactions (the TxManager is also in charge of making the forge call to the rollup smart contract). The TxManager keeps ethereum transactions and: 1. Waits for the transaction to be accepted 2. Waits for the transaction to be confirmed for N blocks - In forge logic, first prepare a batch and then wait for an available server proof to have all work ready once the proof server is ready. - Remove the `isForgeSequence` method which was querying the smart contract, and instead use notifications sent by the Synchronizer to figure out if it's forging time. - Update test (which is a minimal test to manually see if the coordinator starts) - HistoryDB: - Add method to get the number of batches in a slot (used to detect when a slot has passed the bid winner forging deadline) - Add method to get the best bid and associated coordinator of a slot (used to detect the forgerAddress that can forge the slot) - General: - Rename some instances of `currentBlock` to `lastBlock` to be more clear. - Node: - Connect the API to the node and call the methods to update cached state when the sync advances blocks. - Call methods to update Coordinator state when the sync advances blocks and finds reorgs. - Synchronizer: - Add Auction field in the Stats, which contain the current slot with info about highest bidder and other related info required to know who can forge in the current block. - Better organization of cached state: - On Sync, update the internal cached state - On Init or Reorg, load the state from HistoryDB into the internal cached state.
4 years ago
Redo coordinator structure, connect API to node - API: - Modify the constructor so that hardcoded rollup constants don't need to be passed (introduce a `Config` and use `configAPI` internally) - Common: - Update rollup constants with proper *big.Int when required - Add BidCoordinator and Slot structs used by the HistoryDB and Synchronizer. - Add helper methods to AuctionConstants - AuctionVariables: Add column `DefaultSlotSetBidSlotNum` (in the SQL table: `default_slot_set_bid_slot_num`), which indicates at which slotNum does the `DefaultSlotSetBid` specified starts applying. - Config: - Move coordinator exclusive configuration from the node config to the coordinator config - Coordinator: - Reorganize the code towards having the goroutines started and stopped from the coordinator itself instead of the node. - Remove all stop and stopped channels, and use context.Context and sync.WaitGroup instead. - Remove BatchInfo setters and assing variables directly - In ServerProof and ServerProofPool use context instead stop channel. - Use message passing to notify the coordinator about sync updates and reorgs - Introduce the Pipeline, which can be started and stopped by the Coordinator - Introduce the TxManager, which manages ethereum transactions (the TxManager is also in charge of making the forge call to the rollup smart contract). The TxManager keeps ethereum transactions and: 1. Waits for the transaction to be accepted 2. Waits for the transaction to be confirmed for N blocks - In forge logic, first prepare a batch and then wait for an available server proof to have all work ready once the proof server is ready. - Remove the `isForgeSequence` method which was querying the smart contract, and instead use notifications sent by the Synchronizer to figure out if it's forging time. - Update test (which is a minimal test to manually see if the coordinator starts) - HistoryDB: - Add method to get the number of batches in a slot (used to detect when a slot has passed the bid winner forging deadline) - Add method to get the best bid and associated coordinator of a slot (used to detect the forgerAddress that can forge the slot) - General: - Rename some instances of `currentBlock` to `lastBlock` to be more clear. - Node: - Connect the API to the node and call the methods to update cached state when the sync advances blocks. - Call methods to update Coordinator state when the sync advances blocks and finds reorgs. - Synchronizer: - Add Auction field in the Stats, which contain the current slot with info about highest bidder and other related info required to know who can forge in the current block. - Better organization of cached state: - On Sync, update the internal cached state - On Init or Reorg, load the state from HistoryDB into the internal cached state.
4 years ago
Redo coordinator structure, connect API to node - API: - Modify the constructor so that hardcoded rollup constants don't need to be passed (introduce a `Config` and use `configAPI` internally) - Common: - Update rollup constants with proper *big.Int when required - Add BidCoordinator and Slot structs used by the HistoryDB and Synchronizer. - Add helper methods to AuctionConstants - AuctionVariables: Add column `DefaultSlotSetBidSlotNum` (in the SQL table: `default_slot_set_bid_slot_num`), which indicates at which slotNum does the `DefaultSlotSetBid` specified starts applying. - Config: - Move coordinator exclusive configuration from the node config to the coordinator config - Coordinator: - Reorganize the code towards having the goroutines started and stopped from the coordinator itself instead of the node. - Remove all stop and stopped channels, and use context.Context and sync.WaitGroup instead. - Remove BatchInfo setters and assing variables directly - In ServerProof and ServerProofPool use context instead stop channel. - Use message passing to notify the coordinator about sync updates and reorgs - Introduce the Pipeline, which can be started and stopped by the Coordinator - Introduce the TxManager, which manages ethereum transactions (the TxManager is also in charge of making the forge call to the rollup smart contract). The TxManager keeps ethereum transactions and: 1. Waits for the transaction to be accepted 2. Waits for the transaction to be confirmed for N blocks - In forge logic, first prepare a batch and then wait for an available server proof to have all work ready once the proof server is ready. - Remove the `isForgeSequence` method which was querying the smart contract, and instead use notifications sent by the Synchronizer to figure out if it's forging time. - Update test (which is a minimal test to manually see if the coordinator starts) - HistoryDB: - Add method to get the number of batches in a slot (used to detect when a slot has passed the bid winner forging deadline) - Add method to get the best bid and associated coordinator of a slot (used to detect the forgerAddress that can forge the slot) - General: - Rename some instances of `currentBlock` to `lastBlock` to be more clear. - Node: - Connect the API to the node and call the methods to update cached state when the sync advances blocks. - Call methods to update Coordinator state when the sync advances blocks and finds reorgs. - Synchronizer: - Add Auction field in the Stats, which contain the current slot with info about highest bidder and other related info required to know who can forge in the current block. - Better organization of cached state: - On Sync, update the internal cached state - On Init or Reorg, load the state from HistoryDB into the internal cached state.
4 years ago
  1. package common
  2. import (
  3. "math/big"
  4. ethCommon "github.com/ethereum/go-ethereum/common"
  5. )
  6. const (
  7. // AuctionErrMsgCannotForge is the message returned in forge with the
  8. // address cannot forge
  9. AuctionErrMsgCannotForge = "HermezAuctionProtocol::forge: CANNOT_FORGE"
  10. )
  11. // AuctionConstants are the constants of the Rollup Smart Contract
  12. type AuctionConstants struct {
  13. // Blocks per slot
  14. BlocksPerSlot uint8 `json:"blocksPerSlot"`
  15. // Minimum bid when no one has bid yet
  16. InitialMinimalBidding *big.Int `json:"initialMinimalBidding"`
  17. // First block where the first slot begins
  18. GenesisBlockNum int64 `json:"genesisBlockNum"`
  19. // ERC777 token with which the bids will be made
  20. TokenHEZ ethCommon.Address `json:"tokenHEZ"`
  21. // HermezRollup smartcontract address
  22. HermezRollup ethCommon.Address `json:"hermezRollup"`
  23. // Hermez Governanze Token smartcontract address who controls some parameters and collects HEZ fee
  24. GovernanceAddress ethCommon.Address `json:"governanceAddress"`
  25. }
  26. // SlotNum returns the slot number of a block number
  27. func (c *AuctionConstants) SlotNum(blockNum int64) int64 {
  28. if blockNum >= c.GenesisBlockNum {
  29. return (blockNum - c.GenesisBlockNum) / int64(c.BlocksPerSlot)
  30. } else {
  31. // This result will be negative
  32. return (blockNum - c.GenesisBlockNum) / int64(c.BlocksPerSlot)
  33. }
  34. }
  35. // SlotBlocks returns the first and the last block numbers included in that slot
  36. func (c *AuctionConstants) SlotBlocks(slotNum int64) (int64, int64) {
  37. startBlock := c.GenesisBlockNum + slotNum*int64(c.BlocksPerSlot)
  38. endBlock := startBlock + int64(c.BlocksPerSlot) - 1
  39. return startBlock, endBlock
  40. }
  41. // RelativeBlock returns the relative block number within the slot where the
  42. // block number belongs
  43. func (c *AuctionConstants) RelativeBlock(blockNum int64) int64 {
  44. slotNum := c.SlotNum(blockNum)
  45. return blockNum - (c.GenesisBlockNum + (slotNum * int64(c.BlocksPerSlot)))
  46. }
  47. // AuctionVariables are the variables of the Auction Smart Contract
  48. type AuctionVariables struct {
  49. EthBlockNum int64 `meddler:"eth_block_num"`
  50. // Donation Address
  51. DonationAddress ethCommon.Address `meddler:"donation_address" validate:"required"`
  52. // Boot Coordinator Address
  53. BootCoordinator ethCommon.Address `meddler:"boot_coordinator" validate:"required"`
  54. // Boot Coordinator URL
  55. BootCoordinatorURL string `meddler:"boot_coordinator_url" validate:"required"`
  56. // The minimum bid value in a series of 6 slots
  57. DefaultSlotSetBid [6]*big.Int `meddler:"default_slot_set_bid,json" validate:"required"`
  58. // SlotNum at which the new default_slot_set_bid applies
  59. DefaultSlotSetBidSlotNum int64 `meddler:"default_slot_set_bid_slot_num"`
  60. // Distance (#slots) to the closest slot to which you can bid ( 2 Slots = 2 * 40 Blocks = 20 min )
  61. ClosedAuctionSlots uint16 `meddler:"closed_auction_slots" validate:"required"`
  62. // Distance (#slots) to the farthest slot to which you can bid (30 days = 4320 slots )
  63. OpenAuctionSlots uint16 `meddler:"open_auction_slots" validate:"required"`
  64. // How the HEZ tokens deposited by the slot winner are distributed (Burn: 40% - Donation: 40% - HGT: 20%)
  65. AllocationRatio [3]uint16 `meddler:"allocation_ratio,json" validate:"required"`
  66. // Minimum outbid (percentage) over the previous one to consider it valid
  67. Outbidding uint16 `meddler:"outbidding" validate:"required"`
  68. // Number of blocks at the end of a slot in which any coordinator can forge if the winner has not forged one before
  69. SlotDeadline uint8 `meddler:"slot_deadline" validate:"required"`
  70. }
  71. // Copy returns a deep copy of the Variables
  72. func (v *AuctionVariables) Copy() *AuctionVariables {
  73. vCpy := *v
  74. for i := range v.DefaultSlotSetBid {
  75. vCpy.DefaultSlotSetBid[i] = CopyBigInt(v.DefaultSlotSetBid[i])
  76. }
  77. return &vCpy
  78. }