<p>One idea how to solve it works like this:</p>

<ol>
<li><p>The sender submits the contract trigger transaction as phased with a reveal secret approval model based on the hash of a secret it generates. </p></li>
<li><p>The contract activated by this trigger transaction, submits the response transaction(s) with a composite approval model composed of the same hash of the secret used by the trigger transaction and the trigger transaction full hash.</p></li>
</ol>

<p>What happens next is the following:</p>

<p>If the sender approves the trigger transaction, it can also approve the contract transaction since they rely on the same secret.</p>

<p>If the sender does not approve the trigger transaction both the trigger transaction and the transaction submitted by the contract expire.</p>

<p>If the sender tries to approve the contract transaction but not approve his own transaction, the the contract transaction won't be approved since it also relies on the trigger transaction full hash which is not approved in the blockchain.</p>

<p>To implement this we need at least two changes to the existing design:
1. Trigger a contract by a phased transaction which is not approved yet, which is currently not supported.
2. Enhance the by transaction full hash approval model so it has an option to only become approved if the full hash represents a phased approved transaction and not just a transaction stored in the blockchain like it is now. </p>

CC BY-SA 4.0
2018-08-24T00:39:52.687Z
Thanks! Your solution looks much better than my original proposal, because the complicated checks for the contract runner to be safe from disapproval by the sender would not be necessary.
If the sender is satisfied with the response, everything gets approved - and if not, then everything gets discarded.
Looking forward for this to be implemented :)
d5000
CC BY-SA 4.0
2018-08-23T13:51:11.840Z
2018-08-23T13:51:11.840Z
lyaffe
<p>I asked that question on Bitcointalk, but got no response so far. As Lior has proposed to make Stackexchange the main medium of exchange about Ardor I'm asking here.</p>

<p>As I read in the <a href="https://medium.com/@lyaffe/lightweight-contracts-faq-30273120da9a" rel="nofollow noreferrer">FAQ</a>, the main drawback of Lightweight Contracts is that they are not totally trustless, because you cannot guarantee the "contract owner" really runs the contract.</p>

<p>So for example, if the contract is an "exchange contract" that should give you some token for ARDR (e.g. <a href="https://medium.com/@lyaffe/ardor-lightweight-contracts-use-case-71353abb4384" rel="nofollow noreferrer">this IGNIS/ARDR exchange</a>), then if the contract owner doesn't run the contract, you won't get the tokens (and the contract owner could steal your ARDR).</p>

<p>You can run the contract yourself, but AFAIK you can't achieve that the "contract owner" signs the exchange transaction without himself running it - you can only validate that the contract does what he should do according to the source code. (Correct me if I'm wrong here.)</p>

<p>But perhaps you could do the following:</p>

<ul>
<li><p>You first run the contract yourself and calculate the "expected transaction" that should result from it, based on the input from your planned transaction (in this case, the transaction that rewards you with tokens from your ARDR).</p></li>
<li><p>You now issue a phased transaction ("conditional transaction") with the condition of the "expected transaction" - in the exchange case, that you receive the calculated token amount from the contract account.</p></li>
<li><p>If the contract doesn't run or doesn't give you the expected token amount, the transaction expires at some block in the future.</p></li>
</ul>

<p>This way, the contract owner can only spend the resulting coins when the contract owner runs the contract. So you are safe from "selective scammers" that run contracts once and then never again.</p>

<p>The contract owner is also safe: The contract should be possible to be constructed in a way to check first that it really is able to produce the desired transaction. If not, then he simply doesn't issue the "expected transaction". So nothing happens (only that we have an useless phased transaction recorded on the blockchain, but I think that is a minor issue, and it creates the incentive to only trigger the contract with possible conditions).</p>

<p>Is this scenario possible? I haven't read it in the discussions about Lightweight contracts. If not, I think it would be a nice addition, as then Lighweight Contracts would be as trustless (or almost as trustless) as Ethereum Smart Contracts (or even more, as Ethereum contracts can run out of gas).</p>

<p>AFAIK it would need a new type of Phased Transaction - one similar to the one requiring a linked transaction, but with the ability to not  require the complete transaction hash (which is impossible to calculate in this situation) but the "unsigned" transaction or the amount of a token/coin to receive.</p>

<p>Cheers, d5000</p>

<proof-of-stake><smartcontracts><ardor><lightweight-contracts>
Ardor Lightweight Contracts: (Almost) trustless way with new Phased Transaction type?
d5000
# Ardor Lightweight Contracts: (Almost) trustless way with new Phased Transaction type?

(Asked by: username_0 on 2018-08-22)

I asked that question on Bitcointalk, but got no response so far. As Lior has proposed to make Stackexchange the main medium of exchange about Ardor I'm asking here.

As I read in the [FAQ](https://medium.com/@username_1/lightweight-contracts-faq-30273120da9a), the main drawback of Lightweight Contracts is that they are not totally trustless, because you cannot guarantee the "contract owner" really runs the contract.

So for example, if the contract is an "exchange contract" that should give you some token for ARDR (e.g. [this IGNIS/ARDR exchange](https://medium.com/@username_1/ardor-lightweight-contracts-use-case-71353abb4384)), then if the contract owner doesn't run the contract, you won't get the tokens (and the contract owner could steal your ARDR).

You can run the contract yourself, but AFAIK you can't achieve that the "contract owner" signs the exchange transaction without himself running it - you can only validate that the contract does what he should do according to the source code. (Correct me if I'm wrong here.)

But perhaps you could do the following:

* You first run the contract yourself and calculate the "expected transaction" that should result from it, based on the input from your planned transaction (in this case, the transaction that rewards you with tokens from your ARDR).
* You now issue a phased transaction ("conditional transaction") with the condition of the "expected transaction" - in the exchange case, that you receive the calculated token amount from the contract account.
* If the contract doesn't run or doesn't give you the expected token amount, the transaction expires at some block in the future.

This way, the contract owner can only spend the resulting coins when the contract owner runs the contract. So you are safe from "selective scammers" that run contracts once and then never again.

The contract owner is also safe: The contract should be possible to be constructed in a way to check first that it really is able to produce the desired transaction. If not, then he simply doesn't issue the "expected transaction". So nothing happens (only that we have an useless phased transaction recorded on the blockchain, but I think that is a minor issue, and it creates the incentive to only trigger the contract with possible conditions).

Is this scenario possible? I haven't read it in the discussions about Lightweight contracts. If not, I think it would be a nice addition, as then Lighweight Contracts would be as trustless (or almost as trustless) as Ethereum Smart Contracts (or even more, as Ethereum contracts can run out of gas).

AFAIK it would need a new type of Phased Transaction - one similar to the one requiring a linked transaction, but with the ability to not require the complete transaction hash (which is impossible to calculate in this situation) but the "unsigned" transaction or the amount of a token/coin to receive.

Cheers, username_0

**Tags:** proof-of-stake, smartcontracts, ardor, lightweight-contracts


---

## 1 answers

### Answer by username_1 on 2018-08-23. Score: 2 | Accepted answer

One idea how to solve it works like this:

1. The sender submits the contract trigger transaction as phased with a reveal secret approval model based on the hash of a secret it generates.
2. The contract activated by this trigger transaction, submits the response transaction(s) with a composite approval model composed of the same hash of the secret used by the trigger transaction and the trigger transaction full hash.

What happens next is the following:

If the sender approves the trigger transaction, it can also approve the contract transaction since they rely on the same secret.

If the sender does not approve the trigger transaction both the trigger transaction and the transaction submitted by the contract expire.

If the sender tries to approve the contract transaction but not approve his own transaction, the the contract transaction won't be approved since it also relies on the trigger transaction full hash which is not approved in the blockchain.

To implement this we need at least two changes to the existing design:
1. Trigger a contract by a phased transaction which is not approved yet, which is currently not supported.
2. Enhance the by transaction full hash approval model so it has an option to only become approved if the full hash represents a phased approved transaction and not just a transaction stored in the blockchain like it is now.

> **Comments:**
> **username_0**: Thanks! Your solution looks much better than my original proposal, because the complicated checks for the contract runner to be safe from disapproval by the sender would not be necessary. If the sender is satisfied with the response, everything gets approved - and if not, then everything gets discarded. Looking forward for this to be implemented :)  

---

