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

0 Members and 1 Guest are viewing this topic.

Offline bench

  • Full Member
  • ***
  • Posts: 117
    • View Profile
Re: [Worker Proposal] On-chain smart contracts for Bitshares
« Reply #15 on: October 25, 2018, 12:36:09 am »
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 »

Offline pc

  • Hero Member
  • *****
  • Posts: 1397
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Re: [Worker Proposal] On-chain smart contracts for Bitshares
« Reply #16 on: October 28, 2018, 01:07:53 pm »
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 yury

  • Jr. Member
  • **
  • Posts: 35
    • View Profile
    • openledger.info
Re: [Worker Proposal] On-chain smart contracts for Bitshares
« Reply #17 on: October 31, 2018, 03:39:58 pm »
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 yury

  • Jr. Member
  • **
  • Posts: 35
    • View Profile
    • openledger.info
Re: [Worker Proposal] On-chain smart contracts for Bitshares
« Reply #18 on: November 01, 2018, 02:02:37 pm »

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