[Worker Proposal] On-chain smart contracts for Bitshares

[Pavel]

Fabian,

Thanks for the feedback. We are going to provide our vision. I will keep you and the community updated.

[xeroc]

@Victor118, we have evaluated a concept of sidechain of BitShares with a smart contract.
OL team can implement this solution. If the community is interested in it more than in the ETH VM, we can develop it.

Please let us know. Thanks in advance!



Regards,
        Pavel Sivayev
Openledger ApS
Head of Solution Engineering

As has been discussed previously, the specifications are needed before implementation should be started!
Would love to hear more about how you think sidechain should/could be integrated. The solutions that I have seen
so far are unsatisfying .. Would love to see your proposal and learn how you envision it.

[Pavel]

@Victor118, we have evaluated a concept of sidechain of BitShares with a smart contract.
OL team can implement this solution. If the community is interested in it more than in the ETH VM, we can develop it.

Please let us know. Thanks in advance!



Regards,
        Pavel

[Victor118]

why not a sidechain of bitshares with smart contract

[yury]

Please clarify. If the smart contract wants to create or issue an asset, or transfer tokens to an account, does it have to sign the corresponding transaction? That would mean the script needs to know the private keys, which sounds like a bad idea.

Contract doesn't call operation, it doesn't have private keys. Only an account can call the contract, so, the account signs a transaction.
The whole chain of subsequent operations, or calls to another contract(s), are internal operations that no longer require a signature and are performed on behalf of the calling account within one operation.

If the operations generated by the EVM scripts become part of the blockchain they can be executed by themselves, without running the VM. This would open up the possibllity that nodes run without an active VM. It would also greatly speed up replay.
Note that normal nodes also don't validate transaction signatures. They rely on the witnesses to do that. Witnesses would have to run with active VM of course. They need to keep an eye on each other.

Absolutely all nodes must start the VM and validate transactions (see answer to question 1). "greatly speed up replay" is not our case.
The launch of a virtual machine itself, the loading of a contract and its execution don't carry a very large overhead, as confirmed by our tests. EVM is developed quite efficiently. But the load can really be big, it depends on the complexity of the contracts. However, this is compensated by the payment of the fees in accordance with the computational complexity.

Executing many scripts will take much longer than applying normal transactions. It is inevitable that there will be times when more call_contract operations are queued than can be executed within a single block. Hence my question about a total GAS limit per block. The logic of adding transactions will therefore have to be altered anyway (as well as the handling of pending_transactions).

We have provided "total GAS limit per block". This parameter is configured by the committee. Transactions will not get into the block over the set maximum gas.

When the limit is reached, witnesses will have to select which contracts to execute and which not to. It seems natural (and from the POV of a DAC also profitable) to select the most-paying contracts. Note that these situations can appear and evaporate within only a few blocks, much too quickly for the committee to manually adapt the GAS price.

We have considered this case.  IMHO, this is not an actual task for DPoS: the transaction speed is fast enough; by default, all transactions are queued.
It is unlikely that someone is willing to pay an additional fee for the fact that his transaction was 3-6 seconds faster. The analysis showed that now in BitShares,the occupancy of the blocks is an order(s) of magnitude less.

[yury]

Having an VM is a big bonus for new companies and adoption. Is there an easy way to put a VM on top of BTS without affecting the core?

The only alternative is implementation of a side chain. This is also possible, but is not that convenient for end users. Also requires many organizational efforts to start a new chain.

[pc]

Thanks for your answers!

All "write access" to chain state happens exclusively through normal operations, correct?

Correct. The call_contract is also a normal operation, which also has write access to chain state happens.

How is authentication / authorization handled there?

Just simple like in other operations. Here op.sender is an impacted account (operation signer); the sender must sign the transaction containing this operation.

Please clarify. If the smart contract wants to create or issue an asset, or transfer tokens to an account, does it have to sign the corresponding transaction? That would mean the script needs to know the private keys, which sounds like a bad idea.

Do these contract-generated operations end up in the blocks?

Yes, as in the Ethereum, all internal transactions and events log can be visible.

That would open up the possibility that the VM is implemented as a plugin that is mandatory only for witnesses.

No. It cannot be done. Read-only nodes must also run a virtual machine to check the correctness of the chain.

If the operations generated by the EVM scripts become part of the blockchain they can be executed by themselves, without running the VM. This would open up the possibllity that nodes run without an active VM. It would also greatly speed up replay.

Note that normal nodes also don't validate transaction signatures. They rely on the witnesses to do that. Witnesses would have to run with active VM of course. They need to keep an eye on each other.

IMO committee-defined fees / GAS price is not capable of reacting quickly enough. An alternative might be to let the committee define a minimum GAS price and a maximum amount of GAS per block, and "auction off" the available GAS per block to the pending call_contract operations.

IMHO, this is not an actual task for DPoS: the transaction speed is fast enough; by default, all transactions are queued. If you allow users to offer their gas price, then you also need to manage the transactions in the queue so that those who pay a higher price - go first. Now we consider it does not appropriate to alter the logic of adding transactions to the block.

Executing many scripts will take much longer than applying normal transactions. It is inevitable that there will be times when more call_contract operations are queued than can be executed within a single block. Hence my question about a total GAS limit per block. The logic of adding transactions will therefore have to be altered anyway (as well as the handling of pending_transactions).

When the limit is reached, witnesses will have to select which contracts to execute and which not to. It seems natural (and from the POV of a DAC also profitable) to select the most-paying contracts. Note that these situations can appear and evaporate within only a few blocks, much too quickly for the committee to manually adapt the GAS price.

[bench]

Having an VM is a big bonus for new companies and adoption. Is there an easy way to put a VM on top of BTS without affecting the core?

Which integration does OpenLedger prefer?

Our approach is all about on-chain. We believe smart contract is something that modern blockchain must have. Bitshares is perfect blockchain for business solutions, smart contracts is just one last thing still missing. Regarding performance, it is more a matter of correct pricing model. More paid transactions means more activity in the ecosystem, this is what all stakeholders are looking for. At this time Bitshares is definitely underutilized, there is huge space for transactions count increase.

[yury]

In reply to @xeroc, @bitcrab and @clockwork.

I do appreciate your efforts to keep Bitshares a safe heaven and it seems to me we are talking philosophy in this case. Is Bitshares paradigm is to serve only "safe" or "trusted" services, or is this a blockchain platform that provides any kind of decentralized features so that a user can select between those "validated" features and "risky" ones? As a businessman I see Bitshares mission as a trusted blockchain level service provider, but definitely not a vice squad. If I would be a car producer or dealer and start checking if my cars are being used by decent people only, I would become a bankrupt in a weeks. I mean I would be happy to know only good guys are driving my cars, but this is not a good business idea. I see Bitshares definitely have a lack of adoption as a public blockchain that can be used for business solutions. The only valid business case is DEX and there ain't many DEXes required by people. There must be other cases or soon the blockchain will become a funny toy for cryptoanarchysts and freaks.
Verified system smart contracts is a perfect feature and definitely a USP of Bitshares, but why not giving users a choice?
I would like to be fully transparent, at the moment OpenLedger is close to launching several projects and smart contracts is something that is definitely required for their success. It could be built in system contracts, but it could take a year to inject them to the core according to the current process. Thus we may be forced to move to another blockchain solution although we would love to stay with Bitshares. I do believe there are many other projects that will share the same situation and if Bitshares fail to take new projects onboard, this is the end of the story.
I do agree there should be attentive and wise policy in regard to fees and gas price. I see no security issues technology vise as the solution is implemented as a separate layer, so even if VM is broken for some reason, the core operation do not suffer.
We already have a solution that can be delivered as a side chain to Bitshares, where assets can be moved from chain to chain via decentralized gateways, but it seem to be too complicated for a user and thus may also be not a good business case.

Please share your opinion on the points above, I do feel it is now the right time to discuss the future and paradigm of Bitshares, when the public blockchains are looking for mass adoption after the hype is over.   

[yury]

Thanks, Yury! An interesting proposal.

Is it correct that script execution is exclusively triggered by call_contract operation?

Yes. It is correct.

I. e. it is not possible to have scripts triggered by e. g. incoming payment, order execution, market price changes, block time, etc.?

Yes. Scripts (contracts) are invoked only explicitly, on behalf of a particular account (sender), which pays a commission for this. No triggers for other operations.

All "write access" to chain state happens exclusively through normal operations, correct?

Correct. The call_contract is also a normal operation, which also has write access to chain state happens.

How is authentication / authorization handled there?

Just simple like in other operations. Here op.sender is an impacted account (operation signer); the sender must sign the transaction containing this operation.

Do you support bundling operations into all-or-nothing transactions?

In this implementation, the possibility of calling a contract and other operations within a single transaction is excluded. Perhaps in the future, we will consider the valid combinations. For example, a few normal operations, and at the end call_contract operation. Now it is impossible to do this, otherwise, it is possible to spam the node and load it with calculations for which the user will not pay.

Do these contract-generated operations end up in the blocks?

Yes, as in the Ethereum, all internal transactions and events log can be visible.

That would open up the possibility that the VM is implemented as a plugin that is mandatory only for witnesses.

No. It cannot be done. Read-only nodes must also run a virtual machine to check the correctness of the chain.

What happens when a call_contract operation is rolled back, e. g. if it was part of a transaction with a subsequent operation that failed? Is the GAS fee also paid in that case?

Such a transaction is prohibited. If the transaction has call_contract_operation, then other operations are not allowed, the node will not accept it.

Since BitShares is operating with very tight timing constraints, is it possible to limit the total amount of GAS spent per block?

Yes. There is such a parameter block gas limit from Ethereum.

IMO committee-defined fees / GAS price is not capable of reacting quickly enough. An alternative might be to let the committee define a minimum GAS price and a maximum amount of GAS per block, and "auction off" the available GAS per block to the pending call_contract operations.

IMHO, this is not an actual task for DPoS: the transaction speed is fast enough; by default, all transactions are queued. If you allow users to offer their gas price, then you also need to manage the transactions in the queue so that those who pay a higher price - go first. Now we consider it does not appropriate to alter the logic of adding transactions to the block.

[clockwork]

Finally got the time to give my $0.02 on this.

Although I was the one that kind of opened the discussion on this again with my issue on Github, I share many of the same concerns as xeroc.

Faulty/buggy smart-contracts can cause a lot of trouble in the community and open up a lot of FUD attacks against BitShares. What's more, BitShares is not "big" enough to be able to fight such FUD if (when) it occurs. Let alone that fighting it is a marketing/PR thing which we are notoriously terrible at.

When I originally posted that issue, what I had in mind was a much less powerful contract system, more of a glorified, trustless if-this-then-that (IFTTT) scripting environment.

The problem with that is that it requires a completely custom setup as I have been unable to find an existing VM/Scripting system with that kind of simplicity/limited capabilities.

Unbeknownst to me at the time, you guys (OL) were working on the EVM port. I think it's a great achievement and I love the fact that we have it available as it is a HUGE statement of the versatility/strength of the BitShares platform as well as the quality of its developers.

Still, I'm very torn on whether this should be added to core or not for reasons above.

One solution (I believe NEO made that choice) was to make creating smart contracts VERY expensive in terms of creation fees, thus ensuring that a) we don't end up with a bunch of silly useless smart contracts that can drag down performance and b) there will be a better chance that some kind of decent quality control/code review is performed on them prior to creation simply by virtue that there is a bigger monetary risk to the creator if they're not careful.

Not sure whether that would be enough though. I want to be convinced as I would love this to be available and work well but I'm very worried  about the effects if it doesn't.

[Thom]

With EVM contracts, you allow anyone to install new code. What happens is that noone knows how *reliable* that contract is! Was
it reviewed? By whom was it reviewed? Was it tested? How was it tested? Ultimately, the users need to *trust* the code? How well
will that work? We've seen with the DAO!

THIS^^^

[bench]

Adding smart contract possibilities is a good thing, but we should not allow smart contracts on the core level.

Performance/costs and security will not rise, when implemented?

[Victor118]

Sorry for my english !
I'm agree, In my opinion it's a must have. Interact in a trustless way with DEX, UIA, SMA ... is a very powerfull feature.
Bitshares is my favorite blockchain, but as a developer it's frustrating to not be able to code Dapps on it.
But GAS system of EVM is awful, in bitshares GAS should be able to be paid in any assets, with the DEX or fee pool it should be possible?

[xeroc]

Cool development, for sure.

Personally, I am not even convinced yet that "smart contracts" (the way Ethereum uses them and allows users
to freely 'install' new ones on-chain) are a viable business long-term.

This has nothing to do with EVM, or OpenLedger per-se, but with how I personally interpret the term "trust-less":
Before bitcoin/blockchain, people had to trust the middle*MAN*, who was a human being and not only may not be trustworthy,
but (what's worse), he might change behavior sometime later.
With the blockchain, people can now (partially) trust a piece of software that replaces the human being. Software does **not**
change mind but always executes "as implemented" - and that's where the problem starts already. We've all seen what
has happend to "the DAO" and how "intention" may not be reflected fully by "implementation". What I want to say is this:
In BitShares, people trust the operation implementations which go through rigorous review by the core development team
and the review of witnesses as well as anyone curious before a network upgrade that introduces new code. Those operations
(fixed smart contracts) are also tested in plenty of unit tests! Ultimately, that means, you end up with a functionality on-chain that
performs the exact way it was specified for (and confirmed by unit tests!).
Those contracts are *reliable* and people can *trust* the development team, procedures, and ecosystem!

With EVM contracts, you allow anyone to install new code. What happens is that noone knows how *reliable* that contract is! Was
it reviewed? By whom was it reviewed? Was it tested? How was it tested? Ultimately, the users need to *trust* the code? How well
will that work? We've seen with the DAO!

Introducing EVM to BitShares now makes things more complicated because you introduce a software where
   people need to trust the code
and mix it with software where
   people trust the development team and procedures in place.

My fears are that BitShares as a trust-less platform may be harmed by individual "smart contracts" that go rough.
We've seen that with "the DAO", we today see it again with EOSbet.
I don't want that for BitShares.


Instead, how about you go the route BEOS goes and span a sidechain? I believe that with this (https://github.com/bitshares/bitshares-core/wiki/SPV)
we might be able to connect graphene chains with each other. That would allow people to move their funds over
to a separate chain and by this also separate concerns...

</imho>

[bitcrab]

up to now I don't think it's a good idea to make Bitshares a smart contract platform.

one big concern is security, yes smart contract can bring great flexibility, but it also bring risk, we have seen many security events that had happened in Ethereum&EOS, Bitshares is a system focus on Finance, we should be more careful while handling this topic.

yes smart contract is a trend for public blockchain, but that does not means each public chain should become a smart contract platform, smart contract is a big new feature and is not so tightly linked to Bitshares' current competitiveness.   

[yury]

I would like to hear more about how BitShares can benefit from connecting to the EVM.  What sort of DAPPs do you think can be facilitated on the BTS blockchain with this development?

Valid question, John! I have mentioned some of them in my original post, but generally speaking, there may be any of them - just look at Ethereum and EOS, any of smart contract that is available there can be implemented on Bitshares when the solution is active. Considering that Bitshares already have DEX and stable coins, building DApps on top of it may be more reasonable than using Ethereum or EOS. Low fees and fast operation are another reasons to select Bitshares for your business app.

Ultimately I can see this as being a way to reinvigorate the perception of BitShares.  If you're reading this you are likely aware of the vast capability of the BTS blockchain.  However, it has become abundantly clear that the term 'smart contract' itself has a social currency all of its own and getting exposure to that may be rewarding for stakeholders.

This is totally inline with our vision. This solution is intended to expand adoption of Bitshares, attract more businesses and users, allow stakeholders to benefit.

[yury]

I tend to think BitShares needs to A) define target audiences and B) list the features and functionality (in priority order) required for each audience identified, including completed, in development and what's next. Yes, that's marketing, but unless we can all point to a document or source that embodies these things BitShares will bounce from one pinball bumper to the next in reaction to the community concern of the day. We won't be focused and progress will be what it is now.

How does the upcoming HTLC functionality affect this discussion? Will you utilize HTLC to accomplish this?

Thanks a lot for your interest, Thom! I would like to highlight, this solution is not about an interface from Bitshares to any other blockchain (like Ether or EOS), this is Bitshares core update that allows to run custom smart contracts inside Bitshares blockchain. I do agree every blockchain shall has it target audience and designation, but as the technology evolves, some of the functionality is becoming mandatory for a decent ecosystem. I see no reason for Bitshares stay away from the progress just because other networks have custom smart contracts already implemented. Bitshares needs this feature as well. HTLC is another nice feature to have, but has no direct connection to the proposed solution. 

[pc]

Thanks, Yury! An interesting proposal.

Is it correct that script execution is exclusively triggered by call_contract operation? I. e. it is not possible to have scripts triggered by e. g. incoming payment, order execution, market price changes, block time, etc.? That would make things much more controllable wrt time spent on contract execution per block, but would also severely limit the usefulness.

All "write access" to chain state happens exclusively through normal operations, correct? How is authentication / authorization handled there? Do you support bundling operations into all-or-nothing transactions?

Do these contract-generated operations end up in the blocks? That would open up the possibility that the VM is implemented as a plugin that is mandatory only for witnesses.

What happens when a call_contract operation is rolled back, e. g. if it was part of a transaction with a subsequent operation that failed? Is the GAS fee also paid in that case?

Since BitShares is operating with very tight timing constraints, is it possible to limit the total amount of GAS spent per block? IMO committee-defined fees / GAS price is not capable of reacting quickly enough. An alternative might be to let the committee define a minimum GAS price and a maximum amount of GAS per block, and "auction off" the available GAS per block to the pending call_contract operations.

[JohnR]

I take a broad view of 'smart contract' as any predefined digital agreement that executes autonomously without the need for an intermediary or other third party (besides an oracle).  BitShares has smart contracts of a very limited functionality - bitUSD/bitCNY.  These operate without the need for any agent to take action and serve an important role in financial services in a distributed environment.

This proposal deals with integrating general purpose operations (as opposed to specific financial contracts above) also known as "turing completeness".  Of course I welcome any time and effort being put into expanding the capability of the BitShares network.  Especially coming from one of the most respected firms operating on the chain. I would like to hear more about how BitShares can benefit from connecting to the EVM.  What sort of DAPPs do you think can be facilitated on the BTS blockchain with this development?

Ultimately I can see this as being a way to reinvigorate the perception of BitShares.  If you're reading this you are likely aware of the vast capability of the BTS blockchain.  However, it has become abundantly clear that the term 'smart contract' itself has a social currency all of its own and getting exposure to that may be rewarding for stakeholders.

[Thom]

You go Yuri! Well written OP!!

I can see OL has invested a significant amount of time and effort supporting Etherium tokens and this is a logical extension if that effort.

Although I do agree that EOS is in too early a state of evolution for stability and broad consensus (the EOS community is very diverse and many in that community operate under opposing principles and visions of what they want the platform to become), my view is like your #1, and BitShares shouldn't be trying to be all things to all people or businesses. Lets let EOS evolve and if it moves in a direction favorable to BitShares community, integrate with it using atomic cross-chain swaps and run the smart contracts on a platform optimized for it. IDK, but seems to me it will be much easier to implement an interface to the EOS chain than to ETH.

I tend to think BitShares needs to A) define target audiences and B) list the features and functionality (in priority order) required for each audience identified, including completed, in development and what's next. Yes, that's marketing, but unless we can all point to a document or source that embodies these things BitShares will bounce from one pinball bumper to the next in reaction to the community concern of the day. We won't be focused and progress will be what it is now.

How does the upcoming HTLC functionality affect this discussion? Will you utilize HTLC to accomplish this?

[openledger]

Thank you Yury, I hope there will be a good amount of comments to this considering the work you have put into this already.

Time will show if BitShares community is ready to accept proposals like this one meant to help make BitShares an ecosystem useful to all other ecosystems out there. Part of getting the message out is to build and create products allowing other products to flourish using the core of BitShares to do so.

BitShares in its core essence is not really meant to be known by people of name but more of use, and we need this use to be made available in all the ways possible.

This proposal presented here is one of the strongest ones I have seen offered to the BitShares commmunity and I hope it is understood that this is an offer to act upon soonest possible really.

Yury is my VP of Business Development at my R&D office in Minsk, Belarus, called AETSoft (a full member of the High Tech Park of Belarus) and a valuable part of our core team within the OpenLedger organisation.

I hope everyone here will treat this proposal as a serious value added offer to the BitShares ecosystem and let us know soonest possible if the community is up for such added valuable feature.

I do personally hope to have lots of comments here

Yours sincerely

Ronny Boesing
CEO
OpenLedger ApS

[yury]

Dear BitShares community members,
 
While the best minds of the community are doing their best to find new options to expand BitShares adoption worldwide and add more business use cases, the OpenLedger team just cannot stand still.

We’re proud of our previous work, and now we have come up with another big feature that can bring thousands of businesses to the BitShares ecosystem: on-chain smart contracts.

We all know that BitShares is the nearest thing to a perfect blockchain — fast, secure and cost effective, it also provides many valuable features to its users: UIAs, MPAs, DEX, multi-signature accounts, voting. Other valuable standard features are being constantly implemented.

Still, when it comes to business operations, you often find yourself limited by the standard functionality and are not able to implement your custom business logic. Of course, you can create a script on your server and execute BitShares operations in auto mode, but this is not what a true DApp needs. You need on-chain logic executed inside the consensus.

Smart contracts unleash a unique ability for counterparties to operate in a trustless environment and add more traction to BitShares perfect products like MPAs, allowing people to build a complex business logic operating price stable currencies in a decentralized environment.

Numerous business cases can be implemented: scheduled and ongoing (aka token streams) payments, insurance contracts, sophisticated financial products, funds escrow and vesting, crowdfunding automation and many others.

The examples of blockchains like Ethereum and EOS show us that smart contracts and DApps are here to stay and bring with them a new type of economy and a new way of doing business: DAOs, Decentralized Autonomous Organizations. BitShares, of course, will be a part of this bright future.

Although EOS is the most modern technology at the moment, it is still in its childhood and it is probably too early to be considered a trusted operation environment.

On the other hand, Ethereum Virtual Machine has proven its ability to operate, with thousands of smart contracts already implemented and a huge army of developers ready to implement new DApps. This is the reason we selected Ethereum VM to be integrated into BitShares core and allow on-chain smart contracts to be executed.

OpenLedger team has spent several month working on the solution and at this time we believe it is mature enough to be presented to the public!

Here you can find the solution description: https://drive.google.com/file/d/1NZHPojlyNGaGbAR6L9YmvjJu7_AAXDoY/view?usp=sharing

There has already been a testnet operating for several months, where you can run your smart contracts in Btishares environment. See details here: https://drive.google.com/file/d/1Pfe246M82gPfBF3zbabkYEUazjV-k3kj/view?usp=sharing

There is a technical discussion in GitHub: https://github.com/bitshares/bitshares-core/issues/1182
 
 
We are convinced that this solution can bring many new users to the ecosystem, stimulate its usage and adoption across business environments all over the world, and raise BTS demand and therefore price. 

However, community members have raised concerns, so we would like to start a public discussion of this opportunity and decide if it should be processed as a new WP.
 
Here are some of the concerns raised by BitShares members:

1. BitShares was not originally designed to run custom smart contracts, this is something totally different from the original idea.
==================================
Well, when BitShares were originally started in 2015, custom smart contracts were something extremely new and were not in the scope of the ecosystem. Nowadays, using on-chain scripts and DApps is a mainstream trend in the blockchain industry and there is no reason for BitShares to stay away from it.
 
2. Custom smart contracts may spam, contaminate and flood the blockchain, make it slow and heavy.
==================================
With the implementation of an appropriate fee management process, no spam contract is allowed — any operation is paid, raising BTS demand and price. The blockchain is meant to be used, this is what it was created for, so it doesn’t make sense to limit its usage.

Of course, the service must be well paid, and the BitShares committee will keep an eye on the fee schedule to regulate smart contracts fees and make sure they pay reasonable compensation to block producers.

According to many stress tests, BitShares is able to cope with at least 4,000 TPS, and at the moment the average number of transactions is around 20 TPS, so the blockchain seems to be massively underutilized and still has huge unused capacity.
 
3. There may be fraudulent or illegal contracts running in the network.
===================================
Unfortunately, this is true for any public blockchain and there is no sure remedy against it. Even at the moment there are scam coins and MPAs with 100% market fees operating and trading in BitShares. Implementation of VM changes nothing in this area.   


We do encourage public discussion of this proposal, your feedback is extremely welcomed!