Custom transactions

Question

I appreciate how many applications in theory could be implemented as custom transactions (instead of on-chain smart contracts etc). I fail to understand however how to implement them.

Say for example we want:

• An asset of which you can only have either 0 or 1, or
• A trade deal following an exchange rate published earlier on the chain, or
• An asset you can only trade once each day, or 10 units per 24h, or set number of blocks, or
• Assets of which you can have a negative number, possibly limited by data published by a different party
• etc, etc

How can I build in these restrictions in the mining? They seem simple enough and reading through your (excellent!) blogposts I get the impression it's well within the possibilities of MultiChain.

The only options I see though are currency-like assets, which behave according to a unchangeable number of validations, and streams, which as far as I see do not follow validation rules.

Am I overlooking some functionality or documentation?

Answer 1

You cannot do these things in MultiChain right now. But as you say they could be implemented as custom validation rules on transactions. We're always interested in hearing about genuine use cases where smart contract-like functionality is required - can you share anything about what you're trying to build?

Comments

Oh, too bad... They were academic examples, but for each PoC I try to think up, at least one of such seems to be needed. You state somewhere that "Smart contracts are for blockchain use cases which can’t be implemented with transaction constraints", but apart from the very specific set of transactions constraints used for currency transactions, no transactions constraints can be enforced?

Genuine use case:
Smart energy meters can post each hour how much energy they consumed that hour. Energy providers posting 24h in advance the hourly energy price. From this you can find the energy bill for the customer.
You could expand on this by recording customer payments as well, making transparent how much someone still needs to pay, and provide "credit scores" for how high your energy bill can be before the meters shuts down.
An even further expansion could be to have a bidding market where energy is offered for a certain price and can directly be bought under some restrictions. Then, limitations such as "expires after 15 minutes", "buy at least 10 kWh at a time" etc are needed as well.

Another use case, drawing inspiration from your blog:
Agricultural insurance policy. One party pays some amount to the insurance party to insure his crops for the whole of 2016 (assets transfer + metadata). There is some drought and an oracle posts per 1/1/2017 "80% payout possible" onto the blockchain. The payout can, without a smart contract, not automatically be performed, but worse, the manual payout (initiated by either customer or insurer) can not be validated on-chain.

Thanks for your response and I am very curious to hear your take on these!

---

Thanks for your reply. The main thing I would say about these use cases is: are they really suited to a permissioned blockchain? For example in the energy case why would the payment be made over a blockchain (whose contents can be seen by all participants) rather than in a regular way? And same for the agricultural case - why would the payout be done over the blockchain? We know of course it's possible to think up all sorts of things that could be done over a blockchain that require smart contracts, but when focusing on actual production systems that people want to build and deploy, we find that it rarely comes up.

---

Thanks for your reply! It's still as much a difficult topic as it is interesting. Though I am struggling to find a suitable use case, these ones seem somewhat valid.

The energy case works without the payments as well, where you simply use the chain as immutable bookkeeping - valid energy prices communicated unambiguously and on time, and unchangeable records of the energy consumption. From there, the energy bill is clear and indisputable for both parties. Even though payments could be off-chain, some validations are needed to prevent for example a price communicated too late to be included on the chain. The benefit of on-chain records of payment (not necessarily the payment itself) would allow for added functionality such as an automatically triggered shut-off.

Another use case I can think of is the transfer of consent. In this scenario, a customer can consent to his/her personal data to be shared with a third party, maybe for a limited time. It's a form of the "Interorganizational record keeping" use case where the some of the data is not just passively recorded but used to validate other transactions or records.

If you have "Multiparty aggregation", there are some rules needed, right? Only the current bank of the customer can update his/her data, for example.

All in all it's tough to find (and flesh out) a use case which can add value while only recording passive data (streams) and currency-like assets. My conclusion isn't that we need smart contracts, far from it, I just worry that custom-build mining code will always be necessary!

---

Most of these things can be done by post-facto filtering of the data. For example in the case of banks updating their customer's data, records that aren't signed by the right party ("publisher" in MultiChain streams terms) can be ignored. The only risk with this is a DoS attack by one of the chain's participants, where it spews a ton of records that will be ignored. And in a smart contracting platform there is the exact equivalent of spewing a ton of transactions that are rejected by the smart contract. So as you say, to prevent DoS attacks of this nature, custom filtering of transactions would be required at the mining stage.

---

Thanks, I was looking for such a wording ("post-facto filtering"). That exactly describes the solution I had in mind and was trying to avoid. I'll try to explain why it does not feel "right", although I admit it could work.

I'd say DoS attacks are only one (small) problem. Another problem would be the possible cluttering of the chain with non-valid data. Furthermore the post-facto filtering rules are difficult to synchronize between clients. We should assume we can make all clients filter similarly, so they would always reach the same current state, but this feels like a risky assumption to make. It's hard to test whether we succeeded as well. Maybe it would help to add some monitoring to raise a red flag when a node keeps adding invalid data.

But more importantly, the solution deviates from the blockchain principles by allowing multiple timelines/truths to co-exist on the chain. This moves a big part of the burden of finding a single truth from the miners to the users.

Compare for simplicity with bitcoin: if I find a transaction in the blockchain 10+ blocks ago, I can as end-user assume this was a valid transaction. I do not need to replay the history in its entirety. This seems to me a lot more elegant than recording all attempted transactions and leaving it up to every user to find the end state.

I will let it sink in a bit. Thanks for your replies & insights!