Beanstalk Part 3

Summary

Concurrent Transactions: Imagine two transactions (Tx1 and Tx2) are submitted to the blockchain almost simultaneously, both calling rewardBeans.

rewardBeans Calls rewardToFertilizer: If s.season.fertilizing is true, both transactions will call rewardToFertilizer to distribute Beans to active fertilizers.

Race Condition in rewardToFertilizer: The issue lies within rewardToFertilizer itself. Without proper concurrency controls,
both Tx1 and Tx2 might:

Read the same initial value for s.activeFertilizer (let's say it's 10), indicating sufficient fertilizer.
Process Bean distribution for their respective sets of fertilizers.

This could potentially lead to both transactions exceeding the available fertilizer (if it's less than 10).

Consequences:

Incomplete Fertilizer Reward: Some fertilizers might not receive their intended share of Beans if one transaction depletes the available fertilizer before the other.
Unnecessary Calculations and Storage Writes: Both transactions might perform calculations and potentially write to storage (even if one fails), wasting gas for users.

Tools Used

manual

Recommendations

Utilize optimistic locking with versioning for the s.season struct. Tx1 would proceed with the current version, but Tx2 would fail if the version has changed by another transaction (indicating s.activeFertilizer was modified).