26020 Lab 5: Solidity
security | IT | 代做lab | Solidity代写 | 区块链代写 – 本题是一个利用Solidity进行练习的代做, 对区块链的流程进行训练解析, 涵盖了Solidity等方面, 这是值得参考的lab代写的题目
Joe Razavi and Richard Banach
Make sure you have downloaded Remix from Blackboard:
https://online.manchester.ac.uk/bbcswebdav/pid-13567620-dt-content-rid-70759826_ 1/xid-70759826_ and that you can compile and run programs. To do this, you might need to click on the plug icon on the left hand menu, and made sure Solidity compiler and deploy and run transactions are enabled. This will let you compile and run Solidity programs in Remix as seen in the videos. Remix is a browser based editor, and has been tested for this course on Google Chrome on Linux and Windows. With other browsers you may get strange behaviour. IT is better to edit in a separate text editor and paste into Remix for testing, as it can have problems with saving files and allowing text to be copied out of it in some browsers. Make sure you always have a copy of your code in another editor so that you dont lose your work.
Clone the git lab repositoryCOMP26020-lab5-S-Solidity_ whereusername is replaced by your username. This contains the files you will need for the exercise.
While doing these exercises, refer to the Solidity documentation for version 6:https: //docs.soliditylang.org/en/v0.6.0/.
The exercises concern three contracts which should interact with each other, alongside other contracts which we assume exist (but do not implement or worry about the implementation of). The first contract we consider is a paylock. The idea is that a supplier does some work, which can then be collected by a customer. If the customer collects early, they get a discount, and how much discount they get depends on how early: there are two deadlines. If they miss the second deadline they forfeit their discount altogether.
The blobs indicate possible states of the paylock, and the arrows represent function calls. The Start arrow represents the constructor. The idea is that the functions should only succeed if the paylock is in the state at the beginning of the arrow, and then the resulting state should be the one at the end. Of course, there are other conditions:collect_1_Yshould only succeed if called before the first deadline, and collect_1_Nshould only succeed if called once the first deadline has passed; similar considerations apply to the other twocollectfunctions. Look in the filepaylock.solto see a partially finished implementation of the pay- lock. The first two exercises (see next section) concern only the logic of the paylock. They are about adding features to the implementation, though we never complete a realistic implementation.
The subsequent exercises are about implementing a supplier which has to interact with both the paylock contract and a rental contract which it needs to use to complete its work. As above, we will only model certain aspects of these contracts. On the one hand this makes the exercises manageable, but on the other hand it can be confusing if not pointed out: you would naturally wonder when we would add the rest of the necessary features!
The implementation of the paylock which you are given does not model the passage of time. To do this, we will add atickfunction, representing the passage of one unit of time. We shall assume for the moment that thetickfunction is going to be called by a neutral third party, who we trust to call it at a regular interval. For now we also trust all other contracts in the universenotto call this function. (And assume that the blockchain updates quickly enough that this is a reasonable model of time! This is not how one would deal with time in a real smart contract system.)
EXERCISE (2 marks)
Add anintvariableclockand atickfunction which models the passage of time.
Modify the variouscollectfunctions to adhere to the deadlines, where we consider the first deadline to happen if the clock has reached 4 units of time or more, and the second deadline to be when the clock has increased by 4 units of time or more from whencollect_1_Nwas called.
We now need to make sure thistickfunction can only be called by the agreed third party.
EXERCISE (2 marks)
Add anaddressvariabletimeAddto the contract. Add an argument to the constructor and set the value oftimeAddto that argument.
Now modifytickso that it can only be called by someone from the address timeAdd.
Tip: when testing your code, copy one of the addresses from the Account dropdown menu and paste it into the constructor argument. That should make it easier to experiment.
Look in the filesupplier.txtand paste its contents at the end ofpaylock.sol. Note how theSuppliercontract interacts with the paylock, indicating to the paylock when it has finished its task. In the next exercise, we will make it interact with theRental contract too. The idea is that in order to finish its job, theSuppliermust rent a resource, then return it, before callingfinishwill succeed.
EXERCISE (2 marks)
Add functionsaquire_resourceandreturn_resourcewhich must be called in that order to theSuppliercontract. To do this you will need to add new local variables.
Add a local variable representing an instance of theRentalcontract, and allow the address of an instance ofRentalto be passed as an argument to the constructor. Modify theaquire_resourceandreturn_resourcefunctions so that they call the appropriate functions of theRentalcontract.
Tip: Since the constructor ofSupplierrequires the addresses of aPaylock and aRental, make sure you deploy instances of those first when testing.
We will now make our model of theRentalcontract somewhat more realistic, by requiring the payment of a deposit which is returned once the rented resource is re- turned. For th purposes of the lab we assume that the deposit is1 wei.
Since theRentalcontract is not supposed to assume that it is being called be a Supplier, it should assume that the contract it is connected to implements areceive function; you can read about this in the Solidity language documentation: https://docs.soliditylang.org/en/v0.6.0/contracts.html#receive-ether-function.
Since we are not allowed to assume the calling contract is aSupplier, it is also useful to look at the functions which can be applied to any address: https://docs.soliditylang.org/en/v0.6.0/types.html#members-of-addresses. In fact, our intention is to make as few assumptions about the other contract as possible, so we will use the low-level.call()function. Find out how to make this work and attach a value to it.
EXERCISE (2 marks)
Modify theRentalcontract in the following way. First find the commented line//CHECK FOR PAYMENT HEREand replace it with something which prevents the function from succeeding unless proper payment is made. You will also have to make the functionspayable. Then find the commented line//RETURN DEPOSIT HEREand replace it with a single use of the.callfunction which returns the deposit. Modify theSuppliercontract so that it has areceivefunction, and make sure thatRentaldoes not assume that the contract which calls its functions is an instance ofSupplier. Modify the external function calls made bySupplier toRentalso that they transfer the deposit as appropriate.
At this point you shouldcopy the file supplier.sol to supplier.sol and work in supplier2.sol.
The rental contract as implemented has a security flaw which is described in (which is described in the Reentrancy section of chapter 9 of Antonopouloss bookMas- tering Etherium(available online from the library, and also at https://github.com/ ethereumbook/ethereumbook/blob/develop/09smart-contracts-security.asciidoc).
EXERCISE (1 mark)
Modify theSuppliercontract to take advantage of this security flaw to take any Ether belonging to theRentalcontract. Make sure this work is saved in the filesupplier2.sol
At this point you shouldcopy the file supplier2.sol to suppler3.sol and work in supplier3.sol.
EXERCISE (1 mark)
Re-order the lines of theretrieve_resourcefunction of theRentalcontract so that the vulnerability above is fixed. Make sure this work is saved in the filesupplier2.sol
Note: You need only prevent the attack described here while preserving correct func- tionality; you do not need to solve any other security flaws.
Submission is by gitlab, following the same procedure as the other labs for this unit. Ensure that you have pushed a commit containing your submission (i.e. make sure you have added all files to the repository), tagged with the taglab5-submission, by6pmon26/04.
Check SPOT to make sure your submission has been received correctly, and email me (Joe) if you notice any strange behaviour from SPOT.