Meetings

March 5th Mold meeting minutes

• Q: Should mempool keep future transactions?
  • In Cosmos, the mempool doesn’t keep future transactions. It just rejects them. It's the application’s responsibility to resend the transactions.
  • Currently, the Foundry mempool maintains CurrentQueue and FutureQueue. It’s the mempool’s responsibility to read sequence numbers and move transactions from FutureQueue to CurrentQueue.
  • Conclusion: we will do it in Cosmos style - it will be simpler - Applications can manage their own FutureQueues.
  • To do this, Application needs interfaces to
    • read/write memory, which is not a part of the blockchain state (to manageFutureQueue).
    • add transactions to the mempool.
  • However, we need further discussion regarding this interface.

March 6th Mold meeting minutes

If we don't implement FutureQueue, we cannot propagate future transactions.

Q. Is it hard to implement the propagation functionality? Do we have to propagate future transactions?

• Maybe we can create a separate pool

Do we need FutureQueue?

• Advantage of FutureQueue

  • prevent delay caused by sequential transactions

• Disadvantage of FutureQueue

  • It's hard to maintain FutureQueue
  • Maybe we don't have to maintain FutureQueue with Account model

Conclusion

First requirement

"Sequentially dependent transactions must be able to inserted into a single block"

• Light client requires this as well

Conclusion from the second discussion with @Kwang Yul Seo and @Byeongjee Kang

• "Sequentially dependent transactions must be able to be inserted into a single block" can be solved by loosening CheckTx
  • it's the application developer's responsibility to design CheckTx
• We can solve the problem of ordering txs which have sequential dependencies by introducing the TransactionOrder encoding scheme when calculating priorities.
  • We can encode TransactionOrder struct into a Priority field
  • Or we can use TransactionOrder type directly
    • In this case, MemPool can further optimize its block creation logic.

March 9th Mold meeting minutes

CheckTx interface

We concluded to implement a bulk version of CheckTx, which accepts the whole mempool as the input, and returns a list of Txes to be included in a block and a list of Txes to be remained after filtering.

We should keep a simple, stateless version of CheckTx to guard the mempool from spam Txes.

• This CheckTx will return a bool value only.

We decided to use this interface because it's quite hard to order transactions with a single priority field of CheckTx.

Tx removing interface

There are three candidates:

1. Run (lightweight) CheckTx for every Tx in mempool for each block

   • Pros: application does not have to know about stateless information (mempool)
   • Cons: there might be a performance problem

2. Application calls removeTx(TxHash) directly

   • Cons: application has to keep mempool data by itself
   • Pros: probably faster

3. (Discussed after the meeting) Application calls some bulk version of remove_old_txes

   • Input will be the whole mempool Txes, and output will be Txes after filtering

   Conclusion

   we will choose #3 because it's consistent with our 'bulk CheckTx' design

Evidence handling interface

We may have a separate interface for evidence handling (ex. report_evidence ABCI), but current execute_block with evidences parameter should be sufficient.

In this case, the next proposer will be rewarded as the informant of the evidences, and we concluded that this will be sufficient.

Ordering Txes from various modules

Requirement: Txes should be ordered based on

• correctness (ex. seq)
• efficiency (to maximize fee)

How can we order transactions from different modules?

• Tx from some module can be dependent on a Tx from different module
• coordinator doesn't have enough information to order Txes from all modules

Conclusion: we need to investigate how Cosmos handles this issue

March 11th Mold meeting minutes

DB

• We need to serialize DB values since they will be used by modules of various languages
• We should rename moduleID, because it's DB-specific ID
• Disk writing and merkle root computing in Commit interface should be separated into two interfaces
• DBContext
  • should we expose subspace to application?
• What should be happened if application uses a wrong moduleID?
  • Coordinator can enforce some rule to prevent this
• revert should be exposed to applications
  • Applications should be able to execute transactions by their own, and revert to previous state if it fails.

Intertrait

https://docs.google.com/presentation/d/1LbD4u-XGoh04mYeegQchyvceXUU6KiUvBKs58I7p1is/edit#slide=id.g6f5cef6f59_0_381

• We should have a look at HashDB
• We can have a seminar on proc_macro

March 12th Mold meeting

Module DB interface update

• coordinator interface does not have to be changed to support read-only access to module DB
  • module should be responsible for wrapping data for such uses
• We don't need interface for checkpointing individual storage. Global checkpointing is better
• DbContext needs delete interface
• DbContext should have has interface for optimization

Validator interface update

• remove_old_transaction interface should be changed
  • It should return a list of tags for each input transactions
    • tags
      1. should remain in the mempool
      2. became invalid
      3. valid, but should be removed from the mempool because of low priority
    • 2 and 3 should be separately informed in order to support mempool level optimizations

etc

• To separate the host from modules, we can work on removing application-level code from core
  • We can call the remaining part as the host
• We may skip some e2e tests during mold development to speed up
• mold branch should be rebased with master

March 26th Mold meeting minutes

Context field in coordinator

We will remove context field from the coordinator.

Transaction execution ABCIs(open_block, execute_transactions, and close_block) should pass context as an argument.

The host should provide the application get_state interface so that the application can answer to RPC calls.

transaction signature verification in the host

Transaction signature verification should be done in the host side

• Applications can be simpler
• When we verify multiple signatures at once in the host side, there are some chances of optimization.

March 30th Mold meeting

How to handle seq/fee of transactions?

Some fields of transactions are shared by multiple modules.

How can we handle this?

• module hierarchy (a single super module sees seq of all transactions)

But this is too complex design for solving transaction ordering problem.

It's better to have a special module for transaction ordering

Transaction signature verification in the host?

Signature verification means nothing more than computation to the host, so there is no reason to keep signature verification in the host side.

For flexibility, we should move this to the application side.

Module-side flush interface

Modules should be able to manage storage by their own.

It's better for modules to to use builtin data structure in their languages.

To support this, we should provide some interface to modules.