Skip to content

WarrenPanDDDD/Week3-Assignment

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Week 3 Assignments

Cronos dapp engineer training week3 tasks: FruitStand and E-cheque.

FruitStand

Optimizations I made or consider to make:

  1. Record fibonacci number into storage with a mapping instead of calculating it every time. A maaping is declared as:
mapping (uint => uint) fibResult;

Every time we need the fibonacci numebr of n, we check fibResult first, if it exist in fibResult, we can read it from storage instead of calculate it again; If it doesn't exist in fibResult, we calculate the fibonacci numebr and store it into fibResult, so next time we can read it directly from storage.

This can save gas of payout() function.

  1. I found a bug in the stake logic. Currently when a user stake, we check if this user already has a staking by checking
userStakes[msg.sender].startBlock != 0

Then we payout the $MELON rewards by calling payout(). This is correct so far.

But after that we store a new UserStake with the new stakeAmount, without unstake the previous staking or add the previous staking $WATER to the new UserStake. Hence, user's previous staked $WATER is MISSING.

My solution is, we should add the previous stakeAmount to the new stakeAmount

UserStake memory newStake = UserStake({ startBlock: block.number, stakeAmount: _amount + previousWaterStaked });
userStakes[msg.sender] = newStake;

Which means that user get the $MELON rewards with previous stake, and he want to use the previously staked $WATER and the new $WATER to start a new staking.

  1. We can consider shorten the log messages to save gas.

  2. We can consider simplify the calculation of fibonacci number using fibResult mapping we defined in (1). But this will make fib() no longer a view function.

ChequeBank

Finish base functions and optional functions. Have unit tests. Change some interfaces.

interfaces

  1. deposit. User can deposit Ether to this contract. Will add it to user's balances.
function deposit() payable external {}
  1. withdraw. User can withdraw his ether from contract to his address that is calling this function.
function withdraw(uint amount) external {}
  1. withdrawTo. User can withdraw his ether from contract to a specific address.
function withdrawTo(uint amount, address payable recipient) external {}
  1. redeem. User can redeem a cheque. Notice that I assume this function can only be called to redeem a cheque that hasn't been signed over. If a cheque is signed-over, user should call redeemSignOver() instead.
function redeem(Cheque memory chequeData) external {}
  1. revoke.
  • If a cheque hasn't been signed over, the cheque payer can revoke this cheque. If a cheque has been signed-over and notified, the last 'oldPayee' can revoke the cheque.
  • Notice that I also change the param from 'bytes32 chequeId' to 'Cheque memory chequeData', so I can make use of the payer address in chequeData.
  • There is a possible vulnerability that if a attacker knows a chequeId, he can make a valid cheque with this chequeId, and call revoke(). Then this chequeId is marked as 'revoked' in contract. So when the real cheque with the same chequeId comes to redeem, the redeem will failed because of the chequeId has already revoked.
function revoke(Cheque memory chequeData) external {}
  1. notifySignOver.
  • A user can notify a signOver to the contract. After notify, he have the right to redeem signOver, and the oldPayee of this sign over has right to revoke this cheque.
  • I change the interface param. chequeData is added, and the full history of SignOver[] is provided instead of only the latest signOver. I do this to prevent malicious notify to the contract.
function notifySignOver(SignOver[] memory signOverData, Cheque memory chequeData) external {}
  1. redeemSignOver. The newPayee of the signOver can redeem a signOver after he notify the contract.
function redeemSignOver(Cheque memory chequeData, SignOver[] memory signOverData) external {

events

event userDeposit(address depositer, uint amount);

event userWithdraw(address withdrawer, uint amount);

event userWithdrawTo(address withdrawFrom, address withdrawTo, uint amount);

event userRedeemCheque(address redeemer, bytes32 chequeId, uint amount);

event userNotifySignOver(address notifier, bytes32 chequeId, uint8 counter);

event userRedeemSignOver(address notifier, bytes32 chequeId, uint amount);

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published