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.

138 lines
3.7 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
Update coordinator, call all api update functions - Common: - Rename Block.EthBlockNum to Block.Num to avoid unneeded repetition - API: - Add UpdateNetworkInfoBlock to update just block information, to be used when the node is not yet synchronized - Node: - Call API.UpdateMetrics and UpdateRecommendedFee in a loop, with configurable time intervals - Synchronizer: - When mapping events by TxHash, use an array to support the possibility of multiple calls of the same function happening in the same transaction (for example, a smart contract in a single transaction could call withdraw with delay twice, which would generate 2 withdraw events, and 2 deposit events). - In Stats, keep entire LastBlock instead of just the blockNum - In Stats, add lastL1BatchBlock - Test Stats and SCVars - Coordinator: - Enable writing the BatchInfo in every step of the pipeline to disk (with JSON text files) for debugging purposes. - Move the Pipeline functionality from the Coordinator to its own struct (Pipeline) - Implement shouldL1lL2Batch - In TxManager, implement logic to perform several attempts when doing ethereum node RPC calls before considering the error. (Both for calls to forgeBatch and transaction receipt) - In TxManager, reorganize the flow and note the specific points in which actions are made when err != nil - HistoryDB: - Implement GetLastL1BatchBlockNum: returns the blockNum of the latest forged l1Batch, to help the coordinator decide when to forge an L1Batch. - EthereumClient and test.Client: - Update EthBlockByNumber to return the last block when the passed number is -1.
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. [API]
  2. Address = "localhost:8086"
  3. Explorer = true
  4. UpdateMetricsInterval = "10s"
  5. UpdateRecommendedFeeInterval = "10s"
  6. [Debug]
  7. APIAddress = "localhost:12345"
  8. [StateDB]
  9. Path = "/tmp/iden3-test/hermez/statedb"
  10. [PostgreSQL]
  11. Port = 5432
  12. Host = "localhost"
  13. User = "hermez"
  14. Password = "yourpasswordhere"
  15. Name = "hermez"
  16. [Web3]
  17. URL = "http://localhost:8545"
  18. [Synchronizer]
  19. SyncLoopInterval = "1s"
  20. StatsRefreshPeriod = "1s"
  21. [Synchronizer.StartBlockNum]
  22. Rollup = 19
  23. Auction = 17
  24. WDelayer = 15
  25. [SmartContracts]
  26. Rollup = "0x8EEaea23686c319133a7cC110b840d1591d9AeE0"
  27. Auction = "0x317113D2593e3efF1FfAE0ba2fF7A61861Df7ae5"
  28. WDelayer = "0x5E0816F0f8bC560cB2B9e9C87187BeCac8c2021F"
  29. TokenHEZ = "0x5D94e3e7aeC542aB0F9129B9a7BAdeb5B3Ca0f77"
  30. TokenHEZName = "Hermez Network Token"
  31. [Synchronizer.InitialVariables.Auction]
  32. DonationAddress = "0x0000000000000000000000000000000000000001"
  33. BootCoordinator = "0xb4124cEB3451635DAcedd11767f004d8a28c6eE7"
  34. BootCoordinatorURL = "https://boot.coordinator.io"
  35. DefaultSlotSetBid = [
  36. "10000000000000000000",
  37. "10000000000000000000",
  38. "10000000000000000000",
  39. "10000000000000000000",
  40. "10000000000000000000",
  41. "10000000000000000000",
  42. ]
  43. DefaultSlotSetBidSlotNum = 0
  44. ClosedAuctionSlots = 2
  45. OpenAuctionSlots = 4320
  46. AllocationRatio = [4000, 4000, 2000]
  47. Outbidding = 1000
  48. SlotDeadline = 20
  49. [Synchronizer.InitialVariables.WDelayer]
  50. # HermezRollupAddress =
  51. HermezGovernanceAddress = "0x0000000000000000000000000000000000000001"
  52. EmergencyCouncilAddress = "0x0000000000000000000000000000000000000001"
  53. WithdrawalDelay = 60
  54. EmergencyModeStartingTime = 0
  55. EmergencyMode = false
  56. [Synchronizer.InitialVariables.Rollup]
  57. FeeAddToken = "10"
  58. ForgeL1L2BatchTimeout = 10
  59. WithdrawalDelay = 1209600 # 60 * 60 * 24 * 7 * 2
  60. SafeMode = false
  61. [[Synchronizer.InitialVariables.Rollup.Buckets]]
  62. CeilUSD = 0
  63. Withdrawals = 0
  64. BlockWithdrawalRate = 0
  65. MaxWithdrawals = 0
  66. [[Synchronizer.InitialVariables.Rollup.Buckets]]
  67. CeilUSD = 0
  68. Withdrawals = 0
  69. BlockWithdrawalRate = 0
  70. MaxWithdrawals = 0
  71. [[Synchronizer.InitialVariables.Rollup.Buckets]]
  72. CeilUSD = 0
  73. Withdrawals = 0
  74. BlockWithdrawalRate = 0
  75. MaxWithdrawals = 0
  76. [[Synchronizer.InitialVariables.Rollup.Buckets]]
  77. CeilUSD = 0
  78. Withdrawals = 0
  79. BlockWithdrawalRate = 0
  80. MaxWithdrawals = 0
  81. [[Synchronizer.InitialVariables.Rollup.Buckets]]
  82. CeilUSD = 0
  83. Withdrawals = 0
  84. BlockWithdrawalRate = 0
  85. MaxWithdrawals = 0
  86. [Coordinator]
  87. ForgerAddress = "0x6BB84Cc84D4A34467aD12a2039A312f7029e2071"
  88. ConfirmBlocks = 10
  89. L1BatchTimeoutPerc = 0.6
  90. ProofServerPollInterval = "1s"
  91. SyncRetryInterval = "1s"
  92. [Coordinator.L2DB]
  93. SafetyPeriod = 10
  94. MaxTxs = 512
  95. TTL = "24h"
  96. PurgeBatchDelay = 10
  97. InvalidateBatchDelay = 20
  98. PurgeBlockDelay = 10
  99. InvalidateBlockDelay = 20
  100. [Coordinator.TxSelector]
  101. Path = "/tmp/iden3-test/hermez/txselector"
  102. [Coordinator.BatchBuilder]
  103. Path = "/tmp/iden3-test/hermez/batchbuilder"
  104. [[Coordinator.ServerProofs]]
  105. URL = "http://localhost:3000"
  106. [Coordinator.EthClient]
  107. CallGasLimit = 300000
  108. DeployGasLimit = 1000000
  109. GasPriceDiv = 100
  110. ReceiptTimeout = "60s"
  111. ReceiptLoopInterval = "500ms"
  112. CheckLoopInterval = "500ms"
  113. Attempts = 8
  114. AttemptsDelay = "200ms"
  115. [Coordinator.API]
  116. Coordinator = true
  117. [Coordinator.Debug]
  118. BatchPath = "/tmp/iden3-test/hermez/batchesdebug"