-
java-tron latest updates
-
Address.isContract instructions TIP 44
-
Automatically active non-existent account when transferring TRX/TRC10 asset in a smart contract TIP 54
-
Bad node actors penalty
-
Sakary
- I have some progress about Lite fullnode.
- We've talked about it several weeks ago.
- Now we've done the coding part, and done about 80% unit tests.
-
Elvis
- During the development of smart contracts,
- it is necessary to determine whether an address is a smart contract or not.
- Before TIP 44 is implemented, there were several ways to determine whether an address is a contract address
- or simply an address with known private key, but none of them are perfect.
- On Ethereum, attacks caused by contract invasion lead to extremely economic losses for DApp developers.
- So, developers need a better way to distinguish address type.
- TRON is committed to help developers to develop more secure and reliable smart contracts
- and make the TRON ecosystem more stronger.
- We have taken a series of actions to prevent developers from the risks.
- TIP 44 is one of them.
- TIP 44 provides us a new instruction ISCONTRACT at the TVM level,
- which is used to tell whether an address is a contract address.
- And, a isContract property is added to the address type which allows user to call the ISCONTRACT instruction.
- So the developers can simply use this property in solidity language to tell the address type.
-
Sakary
- Is there is an actual scenario that we have to make sure if an address is a contract one?
- Could you tell me some details about this instruction?
-
Elvis
- Sure.
- For now, it mainly has 2 different types: contract address as a message receiver address or as a sender address.
- When we transfer an address in a smart contract and don't want to trigger the
fallback
method of the others. - we need to determine whether the target address is a contract address.
- When a function in a smart contract does not want to be called by other smart contract addresses,
- it is only allowed to be called by a normal address which with a private key on the chain.
- It is also necessary to determine whether the target address is a contract address.
-
Bruce
- since I am not an expert on smart contract, can you give us some knowledge about the fallback function?
-
Elvis
- So fallback function is a special function in smart contract.
- Each smart contract can have a public unnamed function that has no parameters and return values.
- It is executed on a call to the contract if none of the other functions match the given function signature.
- Furthermore, this function is executed whenever the contract receives TRX without data.
-
Michael
- I find some fallback function is modified by the keyword payable,
- but without any other codes,
- so what does the fallback function use for?
-
Elvis
- Contracts that receive TRX by using send or transfer method,
- but do not define a fallback function will throw an exception,
- sending back the TRX. So if you want your contract to receive TRX,
- you have to implement a payable fallback function.
-
Michael
- If I want to trigger other contract's fallback functions directly in a contract, what should I do?
-
Elvis
- There are two contracts: Test and Caller.
- The callTest function in the Caller contract has two different kind of ways to call the fallback function.
- Firstly, the callTest function calls a function which does not exist in the Test contract
- or use "call.value" to transfer TRX to the Test contract.
- Secondly, the callTest function transfers the Test contract by calling the "transfer" function
- or the "send" function of the Test contract address.
-
Michael
- Can you explain what’s the traditional way to distinguish contract address from normal addresses beside this TIP 44?
-
Elvis
- Actually, Taihao will talks more about the best practise of the implementation.
-
Taihao
- Yes, I’d like to give you more details of what we usually do for contract distinguish
- and take a deeper view of the new way we mentioned in TIP 44.
- Hope this can help you have a better understanding of the differences.
- And hope my introduction can answer your question.
- So, most DApp developers would like to use the following two ways to prevent malicious contract attack.
- Not only on TRON but also on Ethereum.
- Let’s take a look at a classic way:
- General speaking, if an address contains no code,
- it means it is not a smart contract address but a common user address.
- This is true in majority cases.
- So, you just need to check the size for a specific address like what I am showing in the code.
- And to prevent fallback attack, developers usually use this code piece to distinguish an contract address.
- They would like to handle their logic carefully especially when the call is related to their asset.
- Another common code piece is like the second way I am showing,
- which forbid the contract method caller to be an contract.
- And it can prevent the so called revert attack
- or rollback attack and guarantee the contract caller address is a normal address
- with a known private key on the chain.
- Just give you some more details about these two pieces of code,
- the second function also have some limitation,
- since it can only be used to prevent when the caller is an attacker,
- but can’t be suit for all cases.
-
Bruce
- Please explain the specific meaning of the code, such as assembly, externalcodesize etc.
-
Taihao
- Sure, so Solidity defines an assembly language that you can use inline assembly inside Solidity source code.
- Inline assembly in a language is close to the language can be recognized by virtual machine directly.
- And, extcodesize is a function which parameter is an address
- and the return value is the size of the code at a certain address.
- So, for the second contract, which part should I explain?
-
Bruce
- msg.sender and tx.origin please.
-
Taihao
- msg.sender is the sender of a message.
- Message here can be a normal transaction which has signature but also can be something called internal transaction.
- tx.origin is the sender of a transaction and it cannot be a contract.
- So, tx.origin has to be an address with a known privatekey.
-
Bruce
- So, if msg.sender and tx.origin are equal,
- which means msg.sender is also a normal address with a private key, not a contract address.
- Is that right?
-
Taihao
- Yes, exactly. It prevent msg.sender to be a contract address.
-
Sakary
- I think we've already got a lot of ways to distinguish a contract address from common address,
- is it truly necessary to have a new one?
- Any advantages compare to the old ones?
-
Taihao
- Both of the ways mentioned above have their shortage. tx.origin is mainly because it can’t support all use scenarios.
- For the first one.
- You may have notice that I mentioned calculate code size for a specific address can handle majority of the cases,
- but in some special situation, they are not reliable.
- I’m gonna to show you another code here.
- So, hacker can use a method called constructor attack to avoid being notice by the code size check,
- which simply means an attacker can establish a revert attack
- when the attacker deploys a smart contract rather than trigger it.
- Another point is, it is not a good developing experience to use assembly with pure solidity code together,
- we should make the code as simple as we can to avoid other bugs.
- However, isContract property is quite simply to use,
- and can be adapted to be used in any known cases.
- We encourage DApp developers to try it out.
- If you get any problem, please open an issue on GitHub, we are ready to help.
-
Michael
- So this example shows, if an attack contract tries to call the victim from attacker's constructor,
- and victim contract misuses the externalcodesize to distinguish the caller address type,
- the check in victim contract can pass and attacker will be regarded as a normal address
- since its code size is 0.
- Is that what you mean?
-
Taihao
- You get the point.
- When execute code in a constructor,
- the victim contract will always regard the deploying contract size as 0 since it has not be save on blockchain.
-
Michael
- So when we write contract code, can we use iscontract function provided by tip44 to judge?
-
Taihao
- Yes. TIP 44 provide a safe and reliable way. You can trust it.
-
Benson
- I know in TIP 26 we add a new instruction create2,
- and we also have a selfdestruct instruction,
- those two instructions are both related to address status.
- Will TIP 44 impact those two instructions?
-
Taihao
- So, you know self-destruct means a contract suicide itself to be an empty account
- and transfer all its asset to another address.
- For create2, just a brief introduction to remind everyone so that we can be on the same page.
- Create2 is a special instruction similar as create instruction but the exact generated address is predicable,
- while the address generated by create is not predictable.
- So, as you see,
- both of the create2 and selfdestruct instructions will change the states of the target address.
- In this case, you should really check the address state every time you trigger the smart contract
- rather than just store the state in a variable of a smart contract for safety purpose.
-
Sakary
- I want to know something about contract safety, can anyone provide some attacking cases?
-
Cooper
- Hi Sakary, actually I prepared some demo for more explanation.
- I’d like to introduce two attacks here.
- Okey?
-
Sakary
- Sure
-
Cooper
- In 2018, some lucky draw dapps such as luckygo, ToBet were under roll back attack.
- Hacker used inline action to cast roll back attack,
- which means that multiple different actions are in one transaction.
- As long as there is an action exception, the entire transaction will fail,
- and all actions will be rolled back.
- I wrote a demo to explain how roll back attack works.
- And I will share my screen.
- First, the betting operation is performed in Attack contract.
- Victim contract gets value and pays bonus immediately after draws.
- And then, Attack uses the inline action to determine whether it has won.
- If not, an exception is thrown.
- At this time, since the betting action and the attacking action are in the same transaction,
- the exception will cause the bet to fail.
-
Michael
- So this is when the attack contract calls the Victim contract draw method,
- it will decide whether to reverse the attack according to the change of our contract balance,
- also the attached draw tx will be reverted?
-
Cooper
- ok, I will introduce the fallback attack.
- In 2016, the DAO attack incident was the use of fallback attacks by hackers.
- The attack process is as follows:
- Assuming 100 SUN in the Bank contract and 10 SUN in the Attacker attack contract.
- The Attack contract first called the deposit method to send 10 SUN to the Bank contract.
- Then the Attack contract calls withdraw method which calls the Bank’s withdrawBalance method.
- The Bank’s withdrawBalance method sent to the Attack contract 10 SUN by using call.value,
- which will trigger Attack’s fallback function.
- So Attack receives 10 SUN, meanwhile the fallback function calls the withdrawBalance of the Bank contract twice,
- thereby transferring another 20 SUN away.
- And finally, the Bank contract modifies the balance of the Attack contract.
- Through the above steps, the attacker actually transferred 30 SUN from the Bank contract, and Bank lost 20 SUN.
- Any questions?
- Ok. That’s pretty much my sharing.
-
Julian
- If there is no questions for TIP 44, Now I want to introduce the TIP54.
- TIP54 shows how to give TRON virtual machine the ability to activate inactive accounts.
- There are two ways to implement TIP54:
- one is to add an OpCode that can activate the account at the compiler level,
- and the other is the currently implemented method directly performs additional operations on specific behaviors
- at the virtual machine level, which is influence in two aspects:
- When the TRON VM processes the TRX or TRC10 token transfers,
- if the target address is in an inactive state, the address will be activated,
- and then the transfer process will be performed,
- which will additionally consume 25000 of the contract caller's energy
- When the TRON VM processes the suicide instruction of the contract,
- if the recipient address is in an inactive state,
- the address will be activated, and then the suicide process is performed,
- which does not consume additional energy.
- Before this TIP is implemented,
- the way to activate the address was mainly through the system contract:
- this required the caller's non-free frozen bandwidth resources to be consumed,
- or the caller's 0.1 TRX.
- Now, we have the way through smart contract.
- So, this is the basic idea about TIP54, any question so far?
-
Benson
- Can you introduce how one account is activated in TRON?
- I know we can transfer TRX to activate new Account.
- Can you give us more background?
-
Julian
- Sure, Before this TIP54,
- the TRON protocol provided a system contract for createAccount to create and activate accounts.
- In addition, when the system contract transferContract,
- transferAssetContract was executed, a non-existent address would be automatically activated.
- And, After TIP54 takes effect, as I introduced above,
- the account activation operation will also be supported at the VM level.
-
Cathy
- Can you share with us the motivation of adding active account in smart contract?
- since we already have those mechanism to activate new account,
- is this a redundant work?
-
Julian
- I think this TIP is necessary.
- In our first version of design, in order to avoid potential risks,
- we carefully selected non-existent addresses that would not be automatically activated.
- Transfer to non-existent account will lead transaction to be reverted.
- However, it is not the same on Ethereum.
- Developers accustomed to EVM contracts may get confused.
-
Cathy
- I see your point.
- So It’s good for user experience and also a good way to attract new developer to use TRON Network.
-
Julian
- Exactly. Actually this is also obey the evolution path of TRON virtual machine as we set.
- We are trying to introduce more system contract functionality to smart contract.
- Assign more privilege and flexibility to DApp developers.
- For more contract implementation details, you can consult Lainey,
- our expert on smart contracts.
- Lainey, can you give us more outputs?
-
Lainey
- Thank Julian, I’d like to show you some specific code here.
- And I’m gonna share my screen.
- OK, Imagine a smart contract, users can use this contract to perform TRX batch transferring.
- What the contract trying to do is a fund distribution.
- You may notice some shortage here.
- Before TIP54 takes effect,
- there will be obvious problems: any unactivated account address Will cause the REVERT of the entire transaction.
- The caller cannot accurately determine which address is not activated in the contract,
- but has to use other ways to guarantee all address as a parameter is activated outside the contract scope.
- The receiver may have to activate the account by themselves,
- which is also a large amount of work, not good for contract user experience.
- OK. Any questions?
-
Michael
- Is this means in the previous version,
- this contract cannot be used if it encounters an inactive receiving address?
- I mean DApp developer can’t use this contract.
-
Lainey
- Not really.
- The caller can choose to query on a trusted node by using the TRON protocol API call
- to ensure that all distribution addresses are activated,
- and remove inactive account addresses for distribution.
-
Michael
- OK. It means users should do some other operations before the contract function is executed.
-
Lainey
- You are right.
- So, you may notice the inconvenience before TIP 54.
- No matter how you deal with this issue,
- it cannot be completed only through the smart contract.
- It requires processing outside the contract and cannot form a unified system.
- After TIP54 takes effect,
- using this contract to send multiple accounts can activate the account at the same time,
- which is consistent with the expectations of developers.
-
Benson
- Can you talk about the OpCode suicide,
- based on your introduction, suicide will help to activate the target address,
- What is the reason of that?
-
Tim
- Hey, I am familiar with this part.
- I’d like to answer your question.
- So, before TIP54 came into effect, when suicide was performed,
- if the recipient address was an inactive account,
- there might be cases where self destruct was not possible.
- The compromise at this time is to manually activate the recipient account before performing self-destruct.
- In order to avoid unnecessary operations like this,
- TIP54 has added the ability to activate the recipient account when executing suicide OpCode
-
Michael
- I noticed that the charge of energy is different compare with previous version of java-tron.
- Could you please introduce the deduction logic and the differences?
-
Tim
- Yes, the charge is different.
- In the original version of java-tron,
- all fee limits were deducted if transfer money to a non-activated address in the VM.
- The community believed that this punishment was unnecessary.
- So, it was changed to just revert the contract without deducting additional energy after upgrade to odx 3.6.0.
- After TIP54, virtual machine will support this behaviour,
- and it charges 25,000 extra energy to activate and create account.
-
Cathy
- How to determine the status of account is active in smart contract?
- Is there a corresponding OpCode?
-
Tim
- This is a good question.
- At present, it can’t determine whether the address of account is active in virtual machine.
- However, it’s easy to find the solution for this issue,
- which is to expand the TVM instruction set,
- and add similar to IsContract's OpCode as an address attribute in Solidity syntax.
- In this way, when performing some TRC20-like transfer operations,
- you can avoid transferring to an inactive account address
-
Cathy
- Will there be some negative effects after this tip is implemented?
-
Tim
- There will have some effects, but it is not a level of risk.
- When smart contract makes TRX or TRC10 transfer in TVM,
- it may be transferred to an address that is not owned by anyone,
- and the asset will be lost.
- Therefore, the developer should be careful and make sure that target address is correct.
- In addition, if developer relies on transferring funds to an account in the contract
- to determine whether the account is active.
- However, relevant instructions cannot be executed after TIP54.
- Thank you.
-
Bruce
- What will happen if i transfer trx to the suicide contract?
-
Tim
- The transaction will be reverted if transfer to a suicide contract.
-
Bruce
- I disagree with you, I think it becomes a normal account, but without a private key
-
Tim
- Oh, yes, sorry, you are right.
-
Bruce
- Any questions for TIP 54?
- Thank you for the details about TIP 54 and TIP 44.
- Ok let's move on to Bad nodes actors penalty.
- How to regulate the nodes behaviors is very important to TRON ecosystem.
- There are some typical bad behaviors like:
- code upgrade not in time, missing blocks and producing empty blocks, and so on
- It is necessary that all the elected SRs have upgraded their node
- to the newest version before opening the voting request for a proposal,
- but often some SR nodes do not upgrade in time,
- resulting in the inability to open the voting of the proposal.
-
Michael
- yes, I know the situation you are talking about.
- Well, in the current situation, the supernode will not be punished.
- I recommend that the other super representatives can resist such malicious supernodes,
- so that he will lose their ability to be a super representative.
- For example, the super representative will lose his qualification temporarily,
- if 80% of all the SRs think he has a malicious actor, such as not upgrade on time.
-
Taihao
- I think this is indeed a method.
- SR is a very important factor in the ecology,
- and it is closely related to the development of the community.
- If they are not active in community governance,
- they cannot really represent the opinions of the community.
- But do you think 80% is a reasonable limit?
-
Michael
- Of course, this is only a preliminary idea,
- if necessary, it is necessary to initiate a TIP to discuss this matter seriously.
- For example, his qualifications can be suspended with as many votes as possible,
- how long the suspension can be suspended, and how to choose a substitute super representative.
- I think there are quite a lot of things to discuss here.
-
Bruce
- I think if this is the case, We must win the approval of the vast majority of SRS.
- Is it also possible to have some SR partners to participate in the voting,
- because after all, it is possible for them to come on the bench,
- and having them to take part in can also remind them to be ready to become formal representatives?
-
Michael
- Good idea, I think we can jointly propose a TIP.
-
Bruce
- On tronscan there is an SR page,
- it shows how many blocks each SR misses.
- Maybe we can calculate how many empty blocks each SR produces,
- and list it on Tronscan, which can be an indicator of their reputation
- which can be displayed as evidence of bad actors.
-
Michael
- I think it is possible to introduce an SR reputation evaluation mechanism,
- just like we have some scoring mechanisms for nodes.
- At present, the total number of each SR production block
- and the total number of miss blocks are recorded on the chain.
- This is an important reference indicator.
- Of course, if you want a sound reputation evaluation mechanism, you need to set other requirements.
-
Taihao
- We still often encounter the problem that some super nodes miss the block for a continuous period of time.
- Now there are no punitive measures.
- If this is related to their reputation and how much they are rewarded,
- I think they will Operate your own nodes more carefully.
-
CryptoChain
- We can prevent the SRs missing blocks, not upgraded from being elected as SRs
- There is a lot of time for the 27 SRs to upgrade their nodes,
- so the others at the bottom can get their positions.
- it is doable to do this.
- You can give them three days to upgrade,
- if they do upgrade, they will not be elected in the next round.
- the votes they receive do not count.
- the others at the bottom that have upgraded their nodes can be elected
- So it is like they have one or two days to complete their their upgrade
- It will prevent the network from breaking down.
-
Taihao
- It is like Bitcoin.
-
Michael
- I think it is a good idea.
- So users can vote for SR with a better reputation,
- and these data used for evaluating the SR reputation can be save on the blockchain all the time.
- If there is a perfect evaluation system,
- I think it can be further combined with incentives.
- The SR with a better reputation can get more incentives.
-
Bruce
- that's pretty much all we need to talk about today
- for the next meeting,
- if there's sth you want to talk about or to discuss,
- you can write the topic on the agenda issue of meeting four after I create the issue.
- todays meeting content will be noted and published on github.
- OK, Our The meeting ends here.
- Have a good day.
- See you guys.
- Bruce
- Taihao
- Cooper
- Tim
- Michael
- Cathy
- Julian
- Sakary
- Elvis
- Lainey
- Benson
- CryptoChain
- ff