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.

90 lines
2.5 KiB

Allow serving API only via new cli command - Add new command to the cli/node: `serveapi` that alows serving the API just by connecting to the PostgreSQL database. The mode flag should me passed in order to select whether we are connecting to a synchronizer database or a coordinator database. If `coord` is chosen as mode, the coordinator endpoints can be activated in order to allow inserting l2txs and authorizations into the L2DB. Summary of the implementation details - New SQL table with 3 columns (plus `item_id` pk). The table only contains a single row with `item_id` = 1. Columns: - state: historydb.StateAPI in JSON. This is the struct that is served via the `/state` API endpoint. The node will periodically update this struct and store it int he DB. The api server will query it from the DB to serve it. - config: historydb.NodeConfig in JSON. This struct contains node configuration parameters that the API needs to be aware of. It's updated once every time the node starts. - constants: historydb.Constants in JSON. This struct contains all the hermez network constants gathered via the ethereum client by the node. It's written once every time the node starts. - The HistoryDB contains methods to get and update each one of these columns individually. - The HistoryDB contains all methods that query the DB and prepare objects that will appear in the StateAPI endpoint. - The configuration used in for the `serveapi` cli/node command is defined in `config.APIServer`, and is a subset of `node.Config` in order to allow reusing the same configuration file of the node if desired. - A new object is introduced in the api: `StateAPIUpdater`, which contains all the necessary information to update the StateAPI in the DB periodically by the node. - Moved the types `SCConsts`, `SCVariables` and `SCVariablesPtr` from `syncrhonizer` to `common` for convenience.
3 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
Allow serving API only via new cli command - Add new command to the cli/node: `serveapi` that alows serving the API just by connecting to the PostgreSQL database. The mode flag should me passed in order to select whether we are connecting to a synchronizer database or a coordinator database. If `coord` is chosen as mode, the coordinator endpoints can be activated in order to allow inserting l2txs and authorizations into the L2DB. Summary of the implementation details - New SQL table with 3 columns (plus `item_id` pk). The table only contains a single row with `item_id` = 1. Columns: - state: historydb.StateAPI in JSON. This is the struct that is served via the `/state` API endpoint. The node will periodically update this struct and store it int he DB. The api server will query it from the DB to serve it. - config: historydb.NodeConfig in JSON. This struct contains node configuration parameters that the API needs to be aware of. It's updated once every time the node starts. - constants: historydb.Constants in JSON. This struct contains all the hermez network constants gathered via the ethereum client by the node. It's written once every time the node starts. - The HistoryDB contains methods to get and update each one of these columns individually. - The HistoryDB contains all methods that query the DB and prepare objects that will appear in the StateAPI endpoint. - The configuration used in for the `serveapi` cli/node command is defined in `config.APIServer`, and is a subset of `node.Config` in order to allow reusing the same configuration file of the node if desired. - A new object is introduced in the api: `StateAPIUpdater`, which contains all the necessary information to update the StateAPI in the DB periodically by the node. - Moved the types `SCConsts`, `SCVariables` and `SCVariablesPtr` from `syncrhonizer` to `common` for convenience.
3 years ago
Allow serving API only via new cli command - Add new command to the cli/node: `serveapi` that alows serving the API just by connecting to the PostgreSQL database. The mode flag should me passed in order to select whether we are connecting to a synchronizer database or a coordinator database. If `coord` is chosen as mode, the coordinator endpoints can be activated in order to allow inserting l2txs and authorizations into the L2DB. Summary of the implementation details - New SQL table with 3 columns (plus `item_id` pk). The table only contains a single row with `item_id` = 1. Columns: - state: historydb.StateAPI in JSON. This is the struct that is served via the `/state` API endpoint. The node will periodically update this struct and store it int he DB. The api server will query it from the DB to serve it. - config: historydb.NodeConfig in JSON. This struct contains node configuration parameters that the API needs to be aware of. It's updated once every time the node starts. - constants: historydb.Constants in JSON. This struct contains all the hermez network constants gathered via the ethereum client by the node. It's written once every time the node starts. - The HistoryDB contains methods to get and update each one of these columns individually. - The HistoryDB contains all methods that query the DB and prepare objects that will appear in the StateAPI endpoint. - The configuration used in for the `serveapi` cli/node command is defined in `config.APIServer`, and is a subset of `node.Config` in order to allow reusing the same configuration file of the node if desired. - A new object is introduced in the api: `StateAPIUpdater`, which contains all the necessary information to update the StateAPI in the DB periodically by the node. - Moved the types `SCConsts`, `SCVariables` and `SCVariablesPtr` from `syncrhonizer` to `common` for convenience.
3 years ago
  1. package api
  2. import (
  3. "errors"
  4. ethCommon "github.com/ethereum/go-ethereum/common"
  5. "github.com/gin-gonic/gin"
  6. "github.com/hermeznetwork/hermez-node/db/historydb"
  7. "github.com/hermeznetwork/hermez-node/db/l2db"
  8. "github.com/hermeznetwork/tracerr"
  9. )
  10. // API serves HTTP requests to allow external interaction with the Hermez node
  11. type API struct {
  12. h *historydb.HistoryDB
  13. cg *configAPI
  14. l2 *l2db.L2DB
  15. chainID uint16
  16. hermezAddress ethCommon.Address
  17. }
  18. // NewAPI sets the endpoints and the appropriate handlers, but doesn't start the server
  19. func NewAPI(
  20. coordinatorEndpoints, explorerEndpoints bool,
  21. server *gin.Engine,
  22. hdb *historydb.HistoryDB,
  23. l2db *l2db.L2DB,
  24. ) (*API, error) {
  25. // Check input
  26. // TODO: is stateDB only needed for explorer endpoints or for both?
  27. if coordinatorEndpoints && l2db == nil {
  28. return nil, tracerr.Wrap(errors.New("cannot serve Coordinator endpoints without L2DB"))
  29. }
  30. if explorerEndpoints && hdb == nil {
  31. return nil, tracerr.Wrap(errors.New("cannot serve Explorer endpoints without HistoryDB"))
  32. }
  33. consts, err := hdb.GetConstants()
  34. if err != nil {
  35. return nil, err
  36. }
  37. a := &API{
  38. h: hdb,
  39. cg: &configAPI{
  40. RollupConstants: *newRollupConstants(consts.Rollup),
  41. AuctionConstants: consts.Auction,
  42. WDelayerConstants: consts.WDelayer,
  43. },
  44. l2: l2db,
  45. chainID: consts.ChainID,
  46. hermezAddress: consts.HermezAddress,
  47. }
  48. v1 := server.Group("/v1")
  49. // Add coordinator endpoints
  50. if coordinatorEndpoints {
  51. // Account
  52. v1.POST("/account-creation-authorization", a.postAccountCreationAuth)
  53. v1.GET("/account-creation-authorization/:hezEthereumAddress", a.getAccountCreationAuth)
  54. // Transaction
  55. v1.POST("/transactions-pool", a.postPoolTx)
  56. v1.GET("/transactions-pool/:id", a.getPoolTx)
  57. }
  58. // Add explorer endpoints
  59. if explorerEndpoints {
  60. // Account
  61. v1.GET("/accounts", a.getAccounts)
  62. v1.GET("/accounts/:accountIndex", a.getAccount)
  63. v1.GET("/exits", a.getExits)
  64. v1.GET("/exits/:batchNum/:accountIndex", a.getExit)
  65. // Transaction
  66. v1.GET("/transactions-history", a.getHistoryTxs)
  67. v1.GET("/transactions-history/:id", a.getHistoryTx)
  68. // Status
  69. v1.GET("/batches", a.getBatches)
  70. v1.GET("/batches/:batchNum", a.getBatch)
  71. v1.GET("/full-batches/:batchNum", a.getFullBatch)
  72. v1.GET("/slots", a.getSlots)
  73. v1.GET("/slots/:slotNum", a.getSlot)
  74. v1.GET("/bids", a.getBids)
  75. v1.GET("/state", a.getState)
  76. v1.GET("/config", a.getConfig)
  77. v1.GET("/tokens", a.getTokens)
  78. v1.GET("/tokens/:id", a.getToken)
  79. v1.GET("/coordinators", a.getCoordinators)
  80. }
  81. return a, nil
  82. }