Advertisement
Guest User

Untitled

a guest
Oct 17th, 2019
452
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 1.99 KB | None | 0 0
  1. External messages can be sent by anyone. And so accept_message is telling collators (who are feeding messages to validators) that contract is willing to pay for message processing.
  2.  
  3. The problem is that collators have no idea how long message processing may take. And so limited amount of resources are allocated essentially for free. Usually contract will attempt to authenticate message sender by it's own mechanism. And if sender is owner, or somehow related, contract will execute accept.
  4.  
  5. Once that happens, there is no reason to keep it running, and it will be passed to validators, who will do actual execution, agree on execution results, commit blocks, etc.
  6.  
  7. If your particular implementation is small enough to fit into those limits. It's still unsafe to accept every message that successfully passed through the handler. It's way easier to guard accept call with checks, than every non throwing branch.
  8.  
  9. Another issue is that when contract encounters a fault it's state gets reverted back. So after contract accepted transaction it's preferable to escape external message handler. Because if it fail after it's storage including replay protection mechanisms such as seqno also will be reverted.
  10.  
  11. That means, that money that were spent by contract on processing that message is gone. And most importantly stored information that would prevent that message from being replayed also isn't there. It can be resent and repeated many times.
  12.  
  13. You may think, that it would be easy for nodes to spot such message, and safe contract from attack. But this requires storing those faulty messages somewhere, and opens DoS attack on nodes them self. So my guess that it's your job not to fail after you accepted external message.
  14.  
  15. And the best way to do that, is to immediately send payload of that message to your contract internal message queue. It will be processed on next "tick" and you can raise errors. Because external messages handler successfully incremented seqno preventing that message from causing additional damage.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement