Jude Nelson, one of the lead developers working on the Clarity smart contracting language (and the Stacks 2.0 blockchain), recently took to Discord for a virtual AMA. Thank you to those that were able to join and ask questions, it was an informative session for everyone!
Make sure to join the next AMA with Head of Engineering at Blockstack PBC, Diwaker Gupta. And, if you’re interested in the Stacks 2.0 Testnet, don’t miss the next Blockstack Community Townhall on March 25th with Muneeb Ali, Blockstack Co-founder.
You can track all Blockstack community events here: https://community.blockstack.org/events
Below, you’ll find everything Jude covered as part of the first #JudeAMA. The text has been lightly edited and reordered to read one question after another.
Please note: Answers were given in real-time via Discord using current knowledge, this is not intended to be a final or permanent resource on any of the topics covered. If you have further questions, please join the channel or reach out to [email protected].
Jude
Hiya folks, let’s get started
Friedger – OpenIntents
#JudeAMA how to best start developing smart contracts? Wait for documentation? Is the documentation on https://docs.blockstack.org/core/smart/overview.html still relevant and worth studying? I am confused about all the repos.
Jude
The best way to start is to download and install the local testnet and start sending transactions. The bug report you opened on the testnet panicking has been fixed in this branch here: https://github.com/blockstack/stacks-blockchain/pull/1319. It should get merged to master sometime this week. Also, the most up-to-date language reference is built into Blockstack Core itself, and is available in src/vm/docs/mod.rs (this gets kept up-to-date with changes to the language itself).
Peter T
JudeAMA Can you please explain more in depth what problems does app chains and app tokens might solve from user point of view and talk about who are users(STX hodlers, technical people or everyday users using apps based on Blockstack) and how do they compare with different solutions(maybe even non crypto related) aiming at the same problem? thanks! 
*Note that app chains do not yet exist, they are a concept for a potential extension of PoX Mining and have not been added to the roadmap as of now.
Jude:
Sure, but this is gonna be a pretty long answer 
So, app tokens and app chains are very different concepts. The Stacks 2.0 chain has support for native app tokens — both fungible tokens and non-fungible tokens — that are instantiated through Clarity. They solve the same kinds of problems that ERC-20 and ERC-721 solve for Ethereum, but IMHO we do a much better job at protecting the user from a lot of common pitfalls (for example, you can set a maximum supply for fungible tokens, which prevents inflation bugs. As another example, Stacks transactions support post-conditions on app tokens that users can use to prevent buggy smart contracts from eating them or stealing them).
App chains are an extension of PoX mining. The Stacks 2.0 chain is a separate blockchain from Bitcoin, but mining its blocks happens by transferring or burning BTC. It turns out, you can do this very same thing on top of the Stacks 2.0 chain — you can run instances of Stacks 2.0 on top of Stacks 2.0. We’ve been tentatively calling these things “app chains,” but I’m not married to the name because I don’t think it adequately captures the main ideas.
The fundamental problem that app chains solve is to provide a Web 3 equivalent of a Web server. Right now, Web 2.0 apps need Web servers to manage global shared mutable state in the app. This is what stops Web 2.0 apps from being completely client-side today.
Examples of global shared mutable state include things like:
- The set of subreddits on Reddit
- The set of blocks in Minecraft
- The set of billing accounts on Netflix
- The set of trending topics on Twitter.
The point is, there are a lot of apps that are currently very hard to build on Web 3 stacks today (including Blockstack) because not all app data is owned by strictly one user. All of these examples are not only owned by multiple users, but also the app needs to ensure that these users can mutate the data and ensure that their changes are globally visible.
App chains address this problem by providing a multi-user computing model that is sufficiently powerful to execute state-transitions on global shared mutable state, but in a way that both frees users and developers alike from having to stand up and operate servers of their own, and in a way that ensures that users are in control of what computations happen on their data.
You can think of an app chain as something like a decentralized AWS lambda function, coupled with an S3 bucket. You can read data from them at any time, since the chainstate is always online (i.e. in a Gaia bucket). You can write data to them by sending transactions to their miner(s), who will incorporate them into blocks and thereby “execute” them on your behalf.
Here’s a concrete example: Consider Facebook, but the state of your wall is managed by an app chain that you and only you can mine. Each user gets their own app chain, and transactions on that app chain are posts to your wall. You’re the sole miner of your app chain (more on this in a sec), so you have the final say on what gets posted. You post to someone else’s app chain by sending a transaction to their app chain, and having them mine it when they’re next online (much like how today, you have to approve other people’s Facebook posts). Under the hood, when you sign into Facebook, you’re also spinning up an in-browser miner that gathers transactions people send (or have sent) to you. The client shows them to you as requests to post, and when you approve their posts, your miner mines a block with them in it. This, in turn, causes your friends’ posts to show up on your wall.
How do you ensure that only you can mine it? How do you delete things? This is managed by a smart contract operating on your app chain’s parent app chain (which can be another app chain, or the Stacks chain itself). In this mining contract, you’d create public methods that allowed you to post new block header hashes, VRF proofs, parent/child linkages, etc. (i.e. the same things that Stacks 2.0 miners have to write to the Bitcoin chain), and you’d additionally structure the contract so that only you could post new blocks. If you wanted to delete posts, you’d just create a fork of your app chain and reorg it by re-mining the subsequent transactions to form a longer chain.
You might have noticed that the act of mining a block on your app chain isn’t free — you’ll be sending a transaction (i.e. a contract-call? transaction) to an existing Stacks app chain, and this requires a transaction fee. This is where things get interesting — the underlying app chain miners ultimately determine what fee you have to pay, and you and they can make an agreement out-of-band whereby you can mine your blocks for free as long as you agree to mine some transactions from the underlying app chain miners (e.g. ads, promotions, etc.). This way, using the system would still be free as long as you’re willing to make this sacrifice. You are of course able to just pay the transaction fee if you don’t want to do this, but it’s important to see here that this inverts the power relationship between you and Facebook — you would be opting into accepting ads posted to your wall for your friends to see, and you’d have the choice of which one(s) to post. The app chain miners would not be able to read your data, nor would they need to read your data in order to do business this way.
Here’s another example of app chains: replace Github’s PR and comments with an app chain that only an OSS project’s developers can mine. The project maintains a supply of project-specific tokens, which users would purchase and attach to issues and PRs in order to get their concerns prioritized by developers. Developers can choose which issues and PRs they’d want to work on (they’d otherwise be working on this for free, in their spare time), and in the act of addressing issues, they’d be making some money by controlling the supply of their project’s tokens. The mining contract would be set up so that only developers can mine blocks, and blocks must be signed off on by a majority of developers. When a developer gets commit access (or has it revoked), the set of developer keys in the contract gets updated to reflect it. This ensures that the developers are able to control the price of the project token, and by doing so, ensure that the price is fair to users and developers alike.
Anyway, wrapping up app chains — they’re like decentralized AWS lambda functions. Anyone can spin them up, and you can decide who gets to submit computing jobs to them. The fact that app chains have tokens gives you lots of different ways to meter computing (which can be turned into revenue streams), and the fact that app chains are operated by a mining contract allows for many different mining participation models (including but not limited to PoX).
dant
#JudeAMA can you talk about the .02% STX holding requirement for stacking? I’ve heard that number reduces the number of Bitcoin transactions as well as helps with Sybil attack resistance. Can you talk about how you arrived at that number? What is the difference in BTC txn volume if the number was .01%? How does .02% help sybil resistence vs .01%? This is not intended to be an argument for lowering the requirement, but just trying to understand the math.
Jude
Excellent questions! The 0.02% requirement was calculated as follows (it’s kind of a long story). The main concern the 0.02% requirement addresses is to strike a balance between allowing as many people to Stack as possible while receiving a Stacking reward in a timely fashion (i.e. once every two weeks, but ideally no less than once a month), and to ensure the system keeps working in a worst-case scenario.
If everything is going well, then users don’t even need to send BTC transactions at all to do Stacking — they’d just send Stacks transactions that registered their reward addresses and delegation parameters. But, the worst-case scenario can be pretty severe:
- Assume no Stacks miner will accept stacking transactions, which would force everyone to send their Stacking transactions to the BTC chain
- Assume that cryptocurrencies undergo another ICO-like spike in price, like what we saw in 2017/2018.
Under the worst-case scenario, every Stacker would send Stacking transactions to the BTC chain. This places pretty tough limits on how many payouts can happen per PoX round, since each additional address increases the size of the BTC transaction by about 50 bytes. In a 2017-like ICO craze, that can get really expensive. Because miners and Stackers have to get their PoX transactions included in the next block, they have to pay on the high-end of the transaction fee rate. Using historical data, this works out to be about 1000 satoshis/byte, or about 19 cents per byte if 1 BTC == $19,000 USD. 1/
Under such circumstances, we’d want the price for a BTC transaction for Stacking or mining to still be “sustainable” — i.e. if you’re doing this for a living, the transaction cost shouldn’t prevent you from participating. If you put 5 PoX addresses into a Bitcoin transaction, plus a change address, plus a 80-byte OP_RETURN, plus one scriptSig, you’re looking at about $89 transaction fees (ouch). For comparison, during 2017 we were seeing people register usernames on BNS for as high as $60 a pop, and a peak cost of $89 isn’t too far off from what we’ve seen users do before. This explains why it’s only 5 addresses per PoX transfer.
So, bringing this all together, if the protocol targets a PoX payout per user that happens 1-2 times per month, and the system must keep working even under highly adversarial conditions that are known to be plausible from historical data, then we’re looking at no more than 5000 addresses per PoX payout period. That, in turn, is how we derived the requirement that a Stacker must prove ownership of 0.02% of the total liquid STX supply. Of course, most people don’t have that much, so SIP 007 also makes a provision for enabling STX holders to pool their STX to reach the 0.02% threshold, and it makes provision to delegate the act of sending the PoX transactions to a third party in a bid to be as accommodating as possible.
If the protocol required STX holders to prove ownership of 0.01%, then there would need to be 10,000 addresses per PoX cycle. This would mean that mining transactions which do the PoX payouts would need to be ~250 bytes bigger (about $50 more expensive in the worst case scenario), or the reward cycle would need to be 2x as long (which gives people less of an incentive to Stack).
Interestingly, the presence of Sybils doesn’t affect Stacking, since the act of having to transfer (or burn) BTC is what enables mining to continue even if the set of miners and stackers is not enumerable.
Friedger – OpenIntents
Re clarity-cli, do you have an example of how to use eval and eval_raw ? #JudeAMA
Jude
Sure:
$ clarity-cli initialize /tmp/vm-state.db
$ clarity-cli launch SP2RC340B27DX3GZ2567BZDRTK5WAEF624AM1FTGD.tokens ./sample-programs/tokens.clar /tmp/vm-state.db
$ cat /tmp/run.clar
;; Give an address some tokens
(token-credit! 'SM2J6ZY48GV1EZ5V2V5RB9MP66SW86PYKKQVX8X0G u12345)
$ ./clarity-cli eval SP2RC340B27DX3GZ2567BZDRTK5WAEF624AM1FTGD.tokens /tmp/run.clar /tmp/vm-state.db
Program executed successfully! Output:
(ok u12345)
$ echo "(print (+ 1 2))" | ./clarity-cli eval_raw
Int(3)
Program executed successfully! Output: 3
Friedger – OpenIntents
#judeAMA when sending transactions to the testnet where do I see the output of the transaction?
Jude
On the local testnet? Right now, you’ll need to look at the logs from the stacks node to see whether or not the transaction got mined
Peter T
I went through your explanation of app chains and have a few follow up questions:
- In your example of a Facebook, where are users data stored? If send a transaction to post on your wall, does it mean that text would be part of transaction or transaction would be more as a command to update your Gaia storage?
- What are biggest differences of this app chains to other global state solutions? Compared to centralised solutions seems to be same things which applies to other decentralised solutions – transparency, automatic enforcement through smart contracts rather than blind trust or law. What are other decentralized solutions which you think might have chance to solve the same problem and what are their cons and pros.
- To be sure I think about this properly. App chains are mainly technological solution to solve shared global state while preserving user control of data (like in Facebook example).
Jude
- Your data always goes to your Gaia hub. The app chain would only store its hash (and possibly some app-specific metadata). Blockchain storage is expensive no matter how you cut it.
- There are infinitely many different solutions, so I can’t compare them all The closest alternative I can think of would be re-organizing Web apps so that instead of putting all your data into a single massive datacenter, everyone owned and operated their own personal Web server sitting at home. Your Facebook posts would be routed to your server, and other people would contact your server to read them. Facebook would crawl everyone’s Web servers in order to produce an aggregate view of everyone’s walls. If you didn’t like Facebook’s index, you could build up and run your own index (and even charge people to access it).
The app chain approach is logically similar to this approach, but with the following additional benefits:
- You get the decentralization benefits of having everyone run their own Web server, but without the high operational and technical overhead of doing so. Operating a single-user app chain could happen entirely inside your login session in your Web browser, and your Gaia hub would take care of serving both your app data and any blocks you mine.
- Unlike Web servers, app chains can’t equivocate. If you mine a block, it can’t be un-mined without also un-mining the block in the underlying blockchain. You can reorg your chain, but not erase the past, since all of your app chain’s forks continue to exist.
- Ownership over an app chain can be shared by as many or as few people as you want (this is hard to do with a Web server).
- Yes; like the web server example above
Important disclaimer
Blockstack PBC is not registered, licensed, or supervised as a broker dealer or investment adviser by the Securities and Exchange Commission (SEC), the Financial Industry Regulatory Authority (FINRA), or any other financial regulatory authority or licensed to provide any financial advice or services.
Forward-looking statements
This communication contains forward-looking statements that are based on our beliefs and assumptions and on information currently available to us. In some cases, you can identify forward-looking statements by the following words: “will,” “expect,” “would,” “intend,” “believe,” or other comparable terminology. Forward-looking statements in this document include, but are not limited to, statements about our plans for developing the platform and potential mining operations. These statements involve risks, uncertainties, assumptions, and other factors that may cause actual results or performance to be materially different. We cannot assure you that the forward-looking statements will prove to be accurate. These forward-looking statements speak only as of the date hereof. We disclaim any obligation to update these forward-looking statements.