Author Topic: [Worker Proposal] On-chain smart contracts for Bitshares  (Read 9218 times)

0 Members and 1 Guest are viewing this topic.

Offline Pavel

  • Newbie
  • *
  • Posts: 3
    • View Profile
Fabian,

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

« Last Edit: December 18, 2018, 09:02:26 pm by Pavel »
Pavel
Openledger Aps

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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.

Offline Pavel

  • Newbie
  • *
  • Posts: 3
    • View Profile
@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
« Last Edit: September 15, 2020, 09:21:38 am by Pavel »
Pavel
Openledger Aps

Offline Victor118

why not a sidechain of bitshares with smart contract

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info

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.

Quote
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.

Quote
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.

Quote
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 Cherniawsky
OpenLedger

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
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.
Yury Cherniawsky
OpenLedger

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Thanks for your answers!


Quote
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.

Quote
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.

Quote
Do these contract-generated operations end up in the blocks?
Yes, as in the Ethereum, all internal transactions and events log can be visible.

Quote
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.

Quote
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.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline 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?
Quote from: charyury
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.
« Last Edit: October 25, 2018, 03:28:25 pm by bench »
Be part of the change and vote for the bitshares-vision proxy!

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
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 Cherniawsky
OpenLedger

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
Thanks, Yury! An interesting proposal.

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

Quote
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.

Quote
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.
Quote
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.

Quote
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.

Quote
Do these contract-generated operations end up in the blocks?
Yes, as in the Ethereum, all internal transactions and events log can be visible.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Yury Cherniawsky
OpenLedger

Offline clockwork

  • Committee member
  • Sr. Member
  • *
  • Posts: 376
    • View Profile
  • BitShares: 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.

Offline 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^^^
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline 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?
Be part of the change and vote for the bitshares-vision proxy!

Offline 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?
« Last Edit: October 16, 2018, 09:56:52 am by Victor118 »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: 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>