Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Changes: 1.added work-delay-factor to the scan state. Work-delay-factor is the number of slots it takes for a considerable number of proofs to be done. Considerable because it depends on how many transactions we always want in a block. For instance, we always want a coinbase and so there has to be at least two proofs available. If it takes 2 slots to generate two proofs then work-delay-factor = 2. Work delay factor essentially increases the tree size (therefore, we need to minimize the delay) so that transactions can be en-queued while snark workers are still generating the required proofs. (#1525) 2. added work-capacity to the scan state In order to control this behaviour so as to not allow free transactions beyond a point, `Work-capacity` is introduced. Work-capacity is the maximum number of jobs there can be at any point in time given a specific transaction capacity and work-delay-factor. The`job_count` field of the scan state tracks the number of jobs currently on the tree. This value is updated using the following equation `job_count += job_count - amount-of-work-done-in-a-block + (no-of-txns-added-in-the-block * 2)` We add `(no-of-txns-added-in-the-block * 2)` jobs which means that both `job_count` and `work-capacity` account for the jobs aren't there on the tree yet for snark workers to pick up. These are the future jobs that will be added when present jobs are completed. Periodically `job_count` will be decremented since the amount of work required for `t` transactions is `(2*t -1)` (#1525 ) 3. perform checks when updating the scan state Check work-capacity every time work is added and transactions are en-queued(#1525 ) 4. Work constraints have now changed. The amount of work and number of transactions included should not cause scan-state's `job_count` to exceed work-capacity. Also, a bunch of changes to include coinbase splitting (#1526 ) 5. Added a sequence number field to the nodes of the parallel scan tree. All the jobs new jobs created will have curr_job_seq_no. This field corresponds to the block number in which a particular Base or a Merge job was added. It was initially used to implement the delay-factor but now remains just for debugging purposes. (#1524 ) 6. added a cli option `work-delay-factor` (#1527 )
- Loading branch information