I'm very grateful and will hold you for that offer of help for the new website. Since OpenLedger was the first actual DEX dapp around BitShares and lasted this long, I believe you could contribute in various ways. For now we are under the pressure of first sprint (polish&launch of new bitshares.org), but as soon as initial Chaos is behind i'll reach you out.

Marketing.

I would recommend that you hold for about 15 days with this proposal and get it polished (e.g proper eta on budgets for ads and worker itself).

bitshares.org will run Google Analytics/AdWords and will have small pro-bono paid campaign in USA which will be used as initial traffic boost and rankings. If we could start this as focused/synced campaign, I would be willing to invite you to GA and give you more info that can actually be very useful for your future development and possibly create co-joint worker for proper Marketing Proposal.


Please let me know your thoughts and have a great day!

Dear Milos, we would be happy to collaborate in the scope of new site implementation. As soon as you are ready, please get in touch with me. In the meanwhile, here is a couple of ideas from us regarding the site update:

- Make sure the site is mobile-friendly.
- Add more “success stories” to the website outlining projects that are currently working on BitShares to show that BitShares is good for businesses.
- Add a Blog section to the website where either BitShares team members or guest authors will be able to publish their use cases, success stories, share news about BitShares and its community. This should help to improve awareness about BitShares.
-SEO:
 -Add metadata on all pages (currently, even the home page misses these elements).
 -Review and re-organize link profile on the website (eliminate broken links, place redirects where needed, etc.).
 -Update info on the BitShares in the most important online directories, catalogs, wiki pages, etc. Right now the info is outdated on many sources.
 - setup and optimize Google analytics(goals tracking, conversions tracking, etc).

 

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.

Thanks a lot, Fabian! We were going to come up with a WP to opensource OL mobile app and develop it further, I wonder if we have some overlaps here, maybe we shall collaborate somehow, or shall it be independent initiatives? Do I understand correctly that you propose to use 1 developer for a year to complete the task? Our initiative is much more prompt.

Dear Bitshares community!

During the last months there were many discussions around the matter, and OpenLedger is happy to offer specific marketing efforts to promote Bitshares magic all over the world.
Originally we were going to offer Bitshares site redesign as well, but at the moment it seems to be addressed by a WP from Milos. We would be happy to participate those efforts, if any help needed, but at the moment I would like to focus on other marketing activities.

Here is what we offer:

1. Paid ads and traffic

OpenLedger team suggests setting up and running two advertising campaigns:

- Display ads campaign on tier 1 blockchain/crypto media sources such as coinmarketcap.com, cryptocompare.com, cointelegraph.com, etc. to attract new users to the platform.
- Remarketing campaign for all bitshares.org visitors to make sure those users see BitShares display ads for the next 90 days after visiting bitshares.org website. This should help to convert visitors into traders more aggressively.

2. Content marketing

OpenLedger proposes to publish a series (5 items) of articles about BitShares platform to cover the following topics:
-BitShares and its advantages for traders
-BitShares and its advantages for businesses
-Stable-coins. Why invest and trade?
-BitShares and its referral program
-BitShares technical overview. Its tech advantages over Bitcoin, Ethereum, etc.

All the articles should be published on tier 1 blockchain/crypto such as cointelegraph.com, newsbtc.com, ccn.com, etc. The goal is to get maximum exposure in front of the crypto audience and increase BitShares brand awareness.


We would like to know your opinion if this is something the community wants. Any proposals and questions are highly appreciated!

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.

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.

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!

bitUSD/CNY face chronic shortages partially because it is expensive to hold the .75 x of surplus collateral.  Widgets that are expensive get supplied in lower quantity.

I have brought the idea in another branch, but would like to raise it one more time in this discussion. Although I'm not fond of the way BSIP42 was pushed, I agree that smart coins shall be enhanced to foster mass adoption. IMO there should be more incentive for people to borrow an MPA.
How about adding one more incentive to those who takes the risk? MPA generally is a good service/product, it has big demand. And therefore it can generate revenue stream (e.g. market fees). IMO it would be nice if those who take the risk and support (borrow) MPA shall have a cut from the revenue. To avoid passive yield harvesting, the borrower shall release borrowed MPA to the open market:
1. An MPA owner specifies market fee portion he would like to share with borrowers.
2. A user borrows the MPA providing the collateral.
3. To receive the cut of the MPA market fees, the user has to place market sell order on MPA:Collateral asset (e.g. bitUSD:BTS) market.
4. As the MPA is being bought and sold by other users, market fee goes to the MPA's owner vesting balance, particular part of it (as specified in 1st step) is proportionally sharedropped to all borrowers who has executed step 3.