From 3687410a20331fbe2ad6e7d73b62823626d91368 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Tue, 9 Apr 2024 12:53:08 -0400 Subject: [PATCH 1/8] Update links to implementation for timelocks --- docs/smart-contracts/data-types/crypto-data-types.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/smart-contracts/data-types/crypto-data-types.md b/docs/smart-contracts/data-types/crypto-data-types.md index 652bb446b..ab476616b 100644 --- a/docs/smart-contracts/data-types/crypto-data-types.md +++ b/docs/smart-contracts/data-types/crypto-data-types.md @@ -97,5 +97,6 @@ Some use cases involve collectively generating a random value or preventing [BPE ## Implementation details -- Michelson: [Operations on timelock](https://tezos.gitlab.io/active/michelson.html#operations-on-timelock) +- Michelson: [Time-lock](https://tezos.gitlab.io/active/timelock.html) - Archetype: [Timelock](https://archetype-lang.org/docs/language-basics/crypto#timelock) +- LIGO: [Timelock](https://ligolang.org/docs/reference/current-reference/?lang=jsligo#timelock) From 82393c5c8084a917c4cc9c8636be66f0a6371787 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Tue, 9 Apr 2024 14:36:46 -0400 Subject: [PATCH 2/8] Separate topic on time-locks with info from opentezos and octez --- .../data-types/crypto-data-types.md | 60 +------------ docs/smart-contracts/timelock.md | 85 +++++++++++++++++++ sidebars.js | 1 + 3 files changed, 90 insertions(+), 56 deletions(-) create mode 100644 docs/smart-contracts/timelock.md diff --git a/docs/smart-contracts/data-types/crypto-data-types.md b/docs/smart-contracts/data-types/crypto-data-types.md index ab476616b..17fb3d966 100644 --- a/docs/smart-contracts/data-types/crypto-data-types.md +++ b/docs/smart-contracts/data-types/crypto-data-types.md @@ -2,7 +2,7 @@ title: Cryptographic data types authors: 'Mathias Hiron (Nomadic Labs), Sasha Aldrick (TriliTech), Tim McMackin (TriliTech)' last_update: - date: 5 October 2023 + date: 9 April 2024 --- Tezos provides hash functions for cryptographic purposes. @@ -37,63 +37,11 @@ It can also be used for identity-based cryptography, single-round multi-party ke - SmartPy: [Cryptography](https://smartpy.io/manual/scenarios/cryptography#cryptography) - Taquito: [Signing data](https://tezostaquito.io/docs/signing/) -## Timelocks +## Time-locks -A `timelock` is a cryptographic primitive that can be used as part of a **commit & reveal** scheme, to provide a guarantee that the information associated to the commit is eventually revealed. +A `timelock` is a cryptographic primitive that can be used as part of a commit-and-reveal scheme, to provide a guarantee that the information associated to the commit is eventually revealed. -### Classical commit & reveal scheme - -Commit & reveal is a scheme that consists of two steps, involving one or more participants: - -- Before a set deadline, each participant makes a decision and publishes a commitment, which is a proof that they have taken a decision that they won't be able to change. -The proof often takes the form of a hash of the data that corresponding to the decision. -- After the deadline, each participant reveals the data corresponding to their commitment. -Other participants can check that the hash of this data indeed corresponds to their previous commitment. - -This scheme makes it possible to prove that a certain decision was taken before some information was revealed. -This information may be the decision of other participants, or some external independent information. - -As an example, imagine that two players want to play the game [rock, paper, scissors](https://en.wikipedia.org/wiki/Rock_paper_scissors) via a smart contract. -As it is impossible to force and verify that the two players reveal their choice between rock, paper or scissors simultaneously, they can use a commit & reveal scheme to do so. - -During the first step, they pick their choice, identified by a number from 1 to 3, put it in a pair with some random data, compute a hash of the result. -This hash is the commitment that they can then send to the contract. - -After both players have sent their commitment, they can reveal by sending the actual data to the contract including the random data. -The contract can verify that the hash of this data matches the previous commitment. -When the two players have revealed their data, the smart contract determines the outcome of the game and distributes rewards accordingly. - -### Not revealing - -One issue with the classical commit & reveal scheme is that after the first step is closed and some information is revealed, one participant may find it advantageous to not reveal at all. -Why reveal if it will only make you lose? For some use cases, this can ruin the whole process. - -One way to address this problem is by setting a financial incentive, such as tokens that people deposit along with their commitments. -After they reveal, they get the tokens back, which encourages them to reveal. - -### Forcing the reveal with a time lock - -In some cases, a financial incentive is not enough by itself. -For example, the benefit of not revealing may outweigh the benefit of revealing, or multiple participants may collaborate and decide not to reveal. - -In this case, you can use a time lock to produce a commitment and force the reveal. - -In this case, instead of using a hash, the data is encrypted using an encryption method that can be cracked with a known algorithm. -The amount of time that it takes to crack the encryption is bounded, which provides a time limit. - -The algorithm used to crack it can't be parallelized, which means there is a limit to how much computing power can be applied to it. -You can estimate the time that it takes for an ordinary computer to crack it and for the fastest possible dedicated hardware to crack it. -Then you can set the time limit by setting the number of iterations in the data encryption. - -For example, assume that you encrypt data in a time lock that you know takes between 10 minutes and 10 hours to decrypt, depending on the hardware. -You can use a commit phase that takes less than 10 minutes, which is not enough time to crack the encryption, so no one can decrypt anyone's commitment. -Then you can use a reveal phase that gives the participants a few minutes to reveal their data. -If a participant doesn't reveal, you can provide a financial reward (funded by the non-revealed participants' deposits) to anyone else to crack the encryption and reveal the data. - -Because it's possible to reveal the data eventually, all participants have an incentive to reveal because they will eventually lose their deposit when someone else cracks and reveals the data. -In this way, time locks work as a deterrent; in practice, participants nearly always reveal rather than forcing someone else to crack the encryption. - -Some use cases involve collectively generating a random value or preventing [BPEV attacks](https://opentezos.com/smart-contracts/avoiding-flaws/#6-not-protecting-against-bots-bpev-attacks). +For information about using time-locks, see [Timelocks](../timelock). ## Implementation details diff --git a/docs/smart-contracts/timelock.md b/docs/smart-contracts/timelock.md new file mode 100644 index 000000000..0d018502e --- /dev/null +++ b/docs/smart-contracts/timelock.md @@ -0,0 +1,85 @@ +--- +title: Time-locks +authors: 'Mathias Hiron (Nomadic Labs), Sasha Aldrick (TriliTech), Tim McMackin (TriliTech)' +last_update: + date: 9 April 2024 +--- + +Time-locks are a way to prevent exploits known as _front-running_, or more properly, Block Producer Extractable Value (BPEV) attacks. +In general, these attacks happen when a client uses information about upcoming transactions to make a profit. + +:::note + +Within decentralized finance, the term "front-running" can be misleading because it implies a relationship between clients and block producers where none may exist. + +In traditional finance, front-running often relies on malicious brokers profiting from advance, nonpublic information about their clients' trades. +For example, a malicious stockbroker may tell friends or family to buy a security for themselves before they execute a client's large buy order, knowing that the client's buy order will drive the price of the security up. + +In decentralized finance, anyone can see incoming transactions, so front-running does not always mean that block producers are acting maliciously or sharing private information with clients. +More often, bots see incoming transactions and insert their own transactions before the incoming transaction runs. + +However, block producers may still be able to profit from advance information about transactions. +For example, they may craft blocks that include a client's transaction and one of their own in an order that guarantees a gain to the block producer. + +::: + +For more information about this kind of attack, see [An analysis of Ethereum front-running and its defense solutions](https://medium.com/degate/an-analysis-of-ethereum-front-running-and-its-defense-solutions-34ef81ba8456). + +## Preventing BPEV attacks with time-locks + +BPEV attacks can be prevented with the use of time-lock encryption, which encrypts a message so it can be decrypted in two ways: + +- The author of the encrypted message provides the unencrypted message and proof that it matches the encrypted message. +- Anyone else can decrypt the message with a certain number of operations. + +With time-locks, an author can encrypt a message in such a way that anyone else can reveal the message, but only after a certain amount of time. +The amount of time depends on the number of sequential operations required to decrypt the message and the hardware used to run the operations. +Therefore, authors can calculate the number of operations needed to keep a typical piece of hardware from breaking the encryption in a given amount of time. +The algorithm used to decrypt the message can't be parallelized, which means that there is a limit to how much computing power can be applied to it. + +## Flow of time-locks in a typical commit-and-reveal scheme + +Time-locks are often used to ensure that a group of users each submit information while keeping their submissions secret for a certain amount of time. +Sometimes this process is called a _commit and reveal scheme_ because all users must commit to their choice before anyone's choices are revealed. + +This is the typical usage pattern of a time-lock: + +1. In the first time period, a contract collects time-lock encrypted values from users along with some valuable deposit, such as tez. +2. In the second time period, after the values are collected, users submit a decryption of the value they submitted with a proof that the decryption is correct. +This prevents users from changing their values. +3. In the third time period, if any value isn't decrypted, anyone can claim some of the deposit by submitting a decryption of the value. +This prevents users from profiting by not revealing their decrypted values or blocking the process. +This period needs to be long enough so that people have enough time to perform the time-lock decryption. +4. Finally, the contract computes some function of the decrypted data. +For example, it might distribute funds to a winner or run an operation that the majority of the users secretly voted for. + +Contracts can assess different penalties for not revealing, depending on whether the user merely failed to submit a decryption for their value or if they also intentionally encrypted invalid data. +They can also distribute different rewards for submitting a correct decryption. + +Because it's possible to reveal the data eventually, all participants have an incentive to reveal because they will eventually lose their deposit when someone else cracks and reveals the data. +In this way, time locks work as a deterrent; in practice, participants nearly always reveal rather than forcing someone else to crack the encryption. +However, the second period needs to be long enough so that bakers cannot easily censor submission of the decryption in a bid to later claim the reward. + +Also, contracts should burn part of a deposit when another user submits a decryption of someone else's value. +Burning a part of the deposit limits attacks where a user gets back their whole deposit by providing the decryption, but in a way that delays everyone else. + +## Example + +Time-locks make it possible to prove that a certain decision was taken before some information was revealed. +This information may be the decision of other participants or some external independent information. + +As an example, imagine that two players want to play the game [rock, paper, scissors](https://en.wikipedia.org/wiki/Rock_paper_scissors) via a smart contract. +If one player can see another player's choice before they choose, they will win every time. +Because it is impossible to force and verify that the two players reveal their choice simultaneously, they can use a commit-and-reveal scheme. + +During the first step, they pick their choice and put it in a pair with some random data. +Then they compute a hash of the result to create a time-lock and send this value to the contract as a commitment. + +After both players have sent their commitment, they can reveal by sending the actual data to the contract including the random data. +The contract can verify that the hash of this data matches the previous commitment. +When the two players have revealed their data, the smart contract determines the outcome of the game and distributes rewards accordingly. + +## References + +- [Time-lock puzzles and timed release Crypto](http://www.hashcash.org/papers/time-lock.pdf>) +- [Not protecting against bots (BPEV attacks)](https://opentezos.com/smart-contracts/avoiding-flaws/#6-not-protecting-against-bots-bpev-attacks) diff --git a/sidebars.js b/sidebars.js index 6f0a518e8..fed7b8ba5 100644 --- a/sidebars.js +++ b/sidebars.js @@ -161,6 +161,7 @@ const sidebars = { 'smart-contracts/events', 'smart-contracts/delegation', 'smart-contracts/multisig', + 'smart-contracts/timelock', 'smart-contracts/oracles', ], }, From ce150b4398c2d4315a8f05a3ede0a2747f81d5df Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Thu, 11 Apr 2024 09:25:01 -0400 Subject: [PATCH 3/8] Rename the file to "timelocks" --- docs/smart-contracts/data-types/crypto-data-types.md | 2 +- docs/smart-contracts/{timelock.md => timelocks.md} | 0 sidebars.js | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) rename docs/smart-contracts/{timelock.md => timelocks.md} (100%) diff --git a/docs/smart-contracts/data-types/crypto-data-types.md b/docs/smart-contracts/data-types/crypto-data-types.md index 17fb3d966..788363bd0 100644 --- a/docs/smart-contracts/data-types/crypto-data-types.md +++ b/docs/smart-contracts/data-types/crypto-data-types.md @@ -41,7 +41,7 @@ It can also be used for identity-based cryptography, single-round multi-party ke A `timelock` is a cryptographic primitive that can be used as part of a commit-and-reveal scheme, to provide a guarantee that the information associated to the commit is eventually revealed. -For information about using time-locks, see [Timelocks](../timelock). +For information about using time-locks, see [Timelocks](../timelocks). ## Implementation details diff --git a/docs/smart-contracts/timelock.md b/docs/smart-contracts/timelocks.md similarity index 100% rename from docs/smart-contracts/timelock.md rename to docs/smart-contracts/timelocks.md diff --git a/sidebars.js b/sidebars.js index fed7b8ba5..daa8dedaa 100644 --- a/sidebars.js +++ b/sidebars.js @@ -161,7 +161,7 @@ const sidebars = { 'smart-contracts/events', 'smart-contracts/delegation', 'smart-contracts/multisig', - 'smart-contracts/timelock', + 'smart-contracts/timelocks', 'smart-contracts/oracles', ], }, From da59c5ea8894f269b65344e9442f6df7bec7d942 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 12 Apr 2024 09:58:37 -0400 Subject: [PATCH 4/8] Clarify timelocks preventing EVs --- docs/smart-contracts/timelocks.md | 57 ++++++++++++++++++++----------- 1 file changed, 38 insertions(+), 19 deletions(-) diff --git a/docs/smart-contracts/timelocks.md b/docs/smart-contracts/timelocks.md index 0d018502e..d0f4cc2f3 100644 --- a/docs/smart-contracts/timelocks.md +++ b/docs/smart-contracts/timelocks.md @@ -1,55 +1,74 @@ --- -title: Time-locks +title: Timelocks authors: 'Mathias Hiron (Nomadic Labs), Sasha Aldrick (TriliTech), Tim McMackin (TriliTech)' last_update: - date: 9 April 2024 + date: 15 April 2024 --- -Time-locks are a way to prevent exploits known as _front-running_, or more properly, Block Producer Extractable Value (BPEV) attacks. -In general, these attacks happen when a client uses information about upcoming transactions to make a profit. +Timelocks are a way to prevent exploits known as _front-running_, or more properly, _extractable value (EV) attacks_. +In general, these attacks happen when a client uses information about an upcoming transaction to make a profit at its expense. :::note Within decentralized finance, the term "front-running" can be misleading because it implies a relationship between clients and block producers where none may exist. In traditional finance, front-running often relies on malicious brokers profiting from advance, nonpublic information about their clients' trades. -For example, a malicious stockbroker may tell friends or family to buy a security for themselves before they execute a client's large buy order, knowing that the client's buy order will drive the price of the security up. +For example, a malicious stockbroker may buy a security for themselves before they execute a client's large buy order, knowing that the client's buy order will drive the price of the security up. In decentralized finance, anyone can see incoming transactions, so front-running does not always mean that block producers are acting maliciously or sharing private information with clients. -More often, bots see incoming transactions and insert their own transactions before the incoming transaction runs. +EV attacks can come from bots that watch for incoming transactions and insert their own transactions before the incoming transaction runs. However, block producers may still be able to profit from advance information about transactions. For example, they may craft blocks that include a client's transaction and one of their own in an order that guarantees a gain to the block producer. +This type of attack is called a block producer extractable value (BPEV) attack. ::: For more information about this kind of attack, see [An analysis of Ethereum front-running and its defense solutions](https://medium.com/degate/an-analysis-of-ethereum-front-running-and-its-defense-solutions-34ef81ba8456). -## Preventing BPEV attacks with time-locks +## Preventing EV attacks with timelocks -BPEV attacks can be prevented with the use of time-lock encryption, which encrypts a message so it can be decrypted in two ways: +Tezos developers can prevent EV attacks with timelock encryption, which encrypts a message so it can be decrypted in two ways: - The author of the encrypted message provides the unencrypted message and proof that it matches the encrypted message. - Anyone else can decrypt the message with a certain number of operations. -With time-locks, an author can encrypt a message in such a way that anyone else can reveal the message, but only after a certain amount of time. +With timelocks, an author can encrypt a message in such a way that anyone else can reveal the message, but only after a certain amount of time. The amount of time depends on the number of sequential operations required to decrypt the message and the hardware used to run the operations. Therefore, authors can calculate the number of operations needed to keep a typical piece of hardware from breaking the encryption in a given amount of time. -The algorithm used to decrypt the message can't be parallelized, which means that there is a limit to how much computing power can be applied to it. +The algorithm used to decrypt the message can't be parallelized, which limits the amount of processing power that can be used to break the encryption because computers can't work together on the decryption. -## Flow of time-locks in a typical commit-and-reveal scheme +dApps that use timelocks to prevent EV attacks work in this general way: -Time-locks are often used to ensure that a group of users each submit information while keeping their submissions secret for a certain amount of time. -Sometimes this process is called a _commit and reveal scheme_ because all users must commit to their choice before anyone's choices are revealed. +1. A user sends a timelock-encrypted order to the dApp. +1. The dApp adds the order to its queue before anyone can see what the order is. +To everyone else, including bakers, bots, and the dApp itself, the order is encrypted and unreadable. +1. No one else can decrypt the order quickly, so they can’t take advantage of it in an EV attack. +1. In the background, the dApp begins decrypting the order. +1. One of two things happen: -This is the typical usage pattern of a time-lock: + - The user submits the decrypted order and the proof that the decryption is accurate to the dApp. + In this case, the dApp doesn't need to decrypt the order. + - The dApp decrypts the order before the user submits the decrypted order, such as if prices changed and the user doesn't want to execute the order anymore. + In this case, the dApp takes a penalty from the order for making it waste processing power on decrypting it. +1. The dApp fulfills the decrypted orders in its queue in the order that they were submitted. -1. In the first time period, a contract collects time-lock encrypted values from users along with some valuable deposit, such as tez. +In practice, DeFi users nearly always submit their decrypted orders before anyone else decrypts them. +They don’t want to pay the penalty and they know how long it will take the dApp to break the order’s encryption. + +## Flow of timelocks in a typical commit-and-reveal scheme + +Timelocks are often used to ensure that a group of users each submit information while keeping their submissions secret for a certain amount of time. +Sometimes this process is called a _commit and reveal scheme_ because all users commit to their choice without seeing the others' choices. + +This is the typical usage pattern of a timelock: + +1. In the first time period, a contract collects timelock encrypted values from users along with some valuable deposit, such as tez. 2. In the second time period, after the values are collected, users submit a decryption of the value they submitted with a proof that the decryption is correct. This prevents users from changing their values. 3. In the third time period, if any value isn't decrypted, anyone can claim some of the deposit by submitting a decryption of the value. This prevents users from profiting by not revealing their decrypted values or blocking the process. -This period needs to be long enough so that people have enough time to perform the time-lock decryption. +This period needs to be long enough so that people have enough time to perform the timelock decryption. 4. Finally, the contract computes some function of the decrypted data. For example, it might distribute funds to a winner or run an operation that the majority of the users secretly voted for. @@ -65,7 +84,7 @@ Burning a part of the deposit limits attacks where a user gets back their whole ## Example -Time-locks make it possible to prove that a certain decision was taken before some information was revealed. +Timelocks make it possible to prove that a certain decision was taken before some information was revealed. This information may be the decision of other participants or some external independent information. As an example, imagine that two players want to play the game [rock, paper, scissors](https://en.wikipedia.org/wiki/Rock_paper_scissors) via a smart contract. @@ -73,7 +92,7 @@ If one player can see another player's choice before they choose, they will win Because it is impossible to force and verify that the two players reveal their choice simultaneously, they can use a commit-and-reveal scheme. During the first step, they pick their choice and put it in a pair with some random data. -Then they compute a hash of the result to create a time-lock and send this value to the contract as a commitment. +Then they compute a hash of the result to create a timelock and send this value to the contract as a commitment. After both players have sent their commitment, they can reveal by sending the actual data to the contract including the random data. The contract can verify that the hash of this data matches the previous commitment. @@ -81,5 +100,5 @@ When the two players have revealed their data, the smart contract determines the ## References -- [Time-lock puzzles and timed release Crypto](http://www.hashcash.org/papers/time-lock.pdf>) +- [Timelock puzzles and timed release Crypto](http://www.hashcash.org/papers/timelock.pdf>) - [Not protecting against bots (BPEV attacks)](https://opentezos.com/smart-contracts/avoiding-flaws/#6-not-protecting-against-bots-bpev-attacks) From e16c897c4b55ead041988133e9039cd7b3a1e15e Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Mon, 22 Apr 2024 15:19:21 -0400 Subject: [PATCH 5/8] Some updateas after blog review --- docs/smart-contracts/timelocks.md | 32 +++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/smart-contracts/timelocks.md b/docs/smart-contracts/timelocks.md index d0f4cc2f3..4d63cff3b 100644 --- a/docs/smart-contracts/timelocks.md +++ b/docs/smart-contracts/timelocks.md @@ -2,7 +2,7 @@ title: Timelocks authors: 'Mathias Hiron (Nomadic Labs), Sasha Aldrick (TriliTech), Tim McMackin (TriliTech)' last_update: - date: 15 April 2024 + date: 22 April 2024 --- Timelocks are a way to prevent exploits known as _front-running_, or more properly, _extractable value (EV) attacks_. @@ -25,6 +25,7 @@ This type of attack is called a block producer extractable value (BPEV) attack. ::: For more information about this kind of attack, see [An analysis of Ethereum front-running and its defense solutions](https://medium.com/degate/an-analysis-of-ethereum-front-running-and-its-defense-solutions-34ef81ba8456). + ## Preventing EV attacks with timelocks @@ -34,27 +35,26 @@ Tezos developers can prevent EV attacks with timelock encryption, which encrypts - Anyone else can decrypt the message with a certain number of operations. With timelocks, an author can encrypt a message in such a way that anyone else can reveal the message, but only after a certain amount of time. -The amount of time depends on the number of sequential operations required to decrypt the message and the hardware used to run the operations. -Therefore, authors can calculate the number of operations needed to keep a typical piece of hardware from breaking the encryption in a given amount of time. -The algorithm used to decrypt the message can't be parallelized, which limits the amount of processing power that can be used to break the encryption because computers can't work together on the decryption. +This duration is based on the time it takes for a single computer to decrypt the commitments because the decryption algorithm can’t be parallelized. +That means that computers can’t easily work together to decrypt it and that adversaries cannot break it even with significant computing power. dApps that use timelocks to prevent EV attacks work in this general way: -1. A user sends a timelock-encrypted order to the dApp. -1. The dApp adds the order to its queue before anyone can see what the order is. -To everyone else, including bakers, bots, and the dApp itself, the order is encrypted and unreadable. -1. No one else can decrypt the order quickly, so they can’t take advantage of it in an EV attack. -1. In the background, the dApp begins decrypting the order. +1. A user sends a timelock-encrypted transaction or operation to the dApp. +1. The dApp adds the transaction to its queue before anyone can see what the transaction is. +To everyone else, including bakers, bots, and the dApp itself, the transaction is encrypted and unreadable. +1. No one else can decrypt the transaction quickly, so they can’t take advantage of it in an EV attack. +1. In the background, the dApp begins decrypting the transaction. 1. One of two things happen: - - The user submits the decrypted order and the proof that the decryption is accurate to the dApp. - In this case, the dApp doesn't need to decrypt the order. - - The dApp decrypts the order before the user submits the decrypted order, such as if prices changed and the user doesn't want to execute the order anymore. - In this case, the dApp takes a penalty from the order for making it waste processing power on decrypting it. -1. The dApp fulfills the decrypted orders in its queue in the order that they were submitted. + - The user submits the decrypted transaction and the proof that the decryption is accurate to the dApp. + In this case, the dApp doesn't need to decrypt the transaction. + - The dApp decrypts the transaction before the user submits the decrypted transaction, such as if prices changed and the user doesn't want to execute the transaction anymore. + In this case, the dApp takes a penalty charge from the transaction for making it waste processing power on decrypting it. +1. The dApp fulfills the decrypted transactions in its queue in the order that they were submitted. -In practice, DeFi users nearly always submit their decrypted orders before anyone else decrypts them. -They don’t want to pay the penalty and they know how long it will take the dApp to break the order’s encryption. +In practice, DeFi users nearly always submit their decrypted transactions before anyone else decrypts them. +They don’t want to pay the penalty and they know how long it will take the dApp to break the transaction’s encryption. ## Flow of timelocks in a typical commit-and-reveal scheme From 840a86952802f500b52cc55a9a12bd6d5b399d82 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Thu, 9 May 2024 11:50:30 -0400 Subject: [PATCH 6/8] Link to Spotlight blog post --- docs/smart-contracts/timelocks.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/smart-contracts/timelocks.md b/docs/smart-contracts/timelocks.md index 4d63cff3b..455047ff3 100644 --- a/docs/smart-contracts/timelocks.md +++ b/docs/smart-contracts/timelocks.md @@ -2,7 +2,7 @@ title: Timelocks authors: 'Mathias Hiron (Nomadic Labs), Sasha Aldrick (TriliTech), Tim McMackin (TriliTech)' last_update: - date: 22 April 2024 + date: 9 May 2024 --- Timelocks are a way to prevent exploits known as _front-running_, or more properly, _extractable value (EV) attacks_. @@ -25,7 +25,6 @@ This type of attack is called a block producer extractable value (BPEV) attack. ::: For more information about this kind of attack, see [An analysis of Ethereum front-running and its defense solutions](https://medium.com/degate/an-analysis-of-ethereum-front-running-and-its-defense-solutions-34ef81ba8456). - ## Preventing EV attacks with timelocks @@ -102,3 +101,4 @@ When the two players have revealed their data, the smart contract determines the - [Timelock puzzles and timed release Crypto](http://www.hashcash.org/papers/timelock.pdf>) - [Not protecting against bots (BPEV attacks)](https://opentezos.com/smart-contracts/avoiding-flaws/#6-not-protecting-against-bots-bpev-attacks) +- [How Tezos timelocks help protect DeFi transactions](https://spotlight.tezos.com/timelocks-defi/) From c45a86eeb6666c9cdcaaa064aa5a63f8638ad428 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Thu, 9 May 2024 11:54:52 -0400 Subject: [PATCH 7/8] tweaks --- docs/smart-contracts/timelocks.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/smart-contracts/timelocks.md b/docs/smart-contracts/timelocks.md index 455047ff3..56c760e04 100644 --- a/docs/smart-contracts/timelocks.md +++ b/docs/smart-contracts/timelocks.md @@ -42,12 +42,11 @@ dApps that use timelocks to prevent EV attacks work in this general way: 1. A user sends a timelock-encrypted transaction or operation to the dApp. 1. The dApp adds the transaction to its queue before anyone can see what the transaction is. To everyone else, including bakers, bots, and the dApp itself, the transaction is encrypted and unreadable. -1. No one else can decrypt the transaction quickly, so they can’t take advantage of it in an EV attack. +No one else can decrypt the transaction quickly, so they can’t take advantage of it in an EV attack. 1. In the background, the dApp begins decrypting the transaction. 1. One of two things happen: - - The user submits the decrypted transaction and the proof that the decryption is accurate to the dApp. - In this case, the dApp doesn't need to decrypt the transaction. + - The user submits the decrypted transaction and the proof that the decryption is accurate to the dApp before the dApp decrypts the transaction. - The dApp decrypts the transaction before the user submits the decrypted transaction, such as if prices changed and the user doesn't want to execute the transaction anymore. In this case, the dApp takes a penalty charge from the transaction for making it waste processing power on decrypting it. 1. The dApp fulfills the decrypted transactions in its queue in the order that they were submitted. @@ -68,14 +67,14 @@ This prevents users from changing their values. 3. In the third time period, if any value isn't decrypted, anyone can claim some of the deposit by submitting a decryption of the value. This prevents users from profiting by not revealing their decrypted values or blocking the process. This period needs to be long enough so that people have enough time to perform the timelock decryption. -4. Finally, the contract computes some function of the decrypted data. +4. Finally, the contract runs some logic based on the decrypted data. For example, it might distribute funds to a winner or run an operation that the majority of the users secretly voted for. Contracts can assess different penalties for not revealing, depending on whether the user merely failed to submit a decryption for their value or if they also intentionally encrypted invalid data. They can also distribute different rewards for submitting a correct decryption. Because it's possible to reveal the data eventually, all participants have an incentive to reveal because they will eventually lose their deposit when someone else cracks and reveals the data. -In this way, time locks work as a deterrent; in practice, participants nearly always reveal rather than forcing someone else to crack the encryption. +In this way, timelocks work as a deterrent; in practice, participants nearly always reveal rather than forcing someone else to crack the encryption. However, the second period needs to be long enough so that bakers cannot easily censor submission of the decryption in a bid to later claim the reward. Also, contracts should burn part of a deposit when another user submits a decryption of someone else's value. From 9ace2b28434be2dfe1906b0b641a3c6c28aefa35 Mon Sep 17 00:00:00 2001 From: Tim McMackin Date: Fri, 10 May 2024 08:10:20 -0400 Subject: [PATCH 8/8] typo in link --- docs/smart-contracts/timelocks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/smart-contracts/timelocks.md b/docs/smart-contracts/timelocks.md index 56c760e04..db73ce7a0 100644 --- a/docs/smart-contracts/timelocks.md +++ b/docs/smart-contracts/timelocks.md @@ -98,6 +98,6 @@ When the two players have revealed their data, the smart contract determines the ## References -- [Timelock puzzles and timed release Crypto](http://www.hashcash.org/papers/timelock.pdf>) +- [Timelock puzzles and timed release Crypto](http://www.hashcash.org/papers/timelock.pdf) - [Not protecting against bots (BPEV attacks)](https://opentezos.com/smart-contracts/avoiding-flaws/#6-not-protecting-against-bots-bpev-attacks) - [How Tezos timelocks help protect DeFi transactions](https://spotlight.tezos.com/timelocks-defi/)