chapter updates

KomodoPlatform · Aug 25, 2018 · 841127d · 841127d
1 parent 5740393
commit 841127d
Show file tree

Hide file tree

Showing 12 changed files with 130 additions and 44 deletions.
diff --git a/Chapter 0 - Bitcoin Protocol Basics → Chapter 00 - Bitcoin Protocol Basics b/Chapter 0 - Bitcoin Protocol Basics → Chapter 00 - Bitcoin Protocol Basics
diff --git a/Chapter 1 - OP_CHECKCRYPTOCONDITION → Chapter 01 - OP_CHECKCRYPTOCONDITION b/Chapter 1 - OP_CHECKCRYPTOCONDITION → Chapter 01 - OP_CHECKCRYPTOCONDITION
diff --git a/Chapter 2 - CC contract basics → Chapter 02 - CC contract basics b/Chapter 2 - CC contract basics → Chapter 02 - CC contract basics
diff --git a/Chapter 3 - CC vins and vouts → Chapter 03 - CC vins and vouts b/Chapter 3 - CC vins and vouts → Chapter 03 - CC vins and vouts
diff --git a/Chapter 4 - CC rpc extensions → Chapter 04 - CC rpc extensions b/Chapter 4 - CC rpc extensions → Chapter 04 - CC rpc extensions
diff --git a/Chapter 5 - CC validation → Chapter 05 - CC validation b/Chapter 5 - CC validation → Chapter 05 - CC validation
diff --git a/Chapter 6 - faucet example → Chapter 06 - faucet example b/Chapter 6 - faucet example → Chapter 06 - faucet example
diff --git a/Chapter 12 - limitless possibilities b/Chapter 12 - limitless possibilities
@@ -0,0 +1,10 @@
+Chapter 12 - limitless possibilities
+As can be seen, CC contracts can do a wide range of things and since they are Turing complete, we know that this is true. However, what is more important is the added security gained from using a utxo based system. While in some ways it is more complex to have to deal with utxo, as can be seen by the above examples, it is either solved and made invisible at the rpc level, or actually used as part of the solution.
+
+Being utxo based, automatically builds in a rate limit to how many tx per block a specific CC contract can do. The state advancing by one transaction at a time is another means that rate limits. Since more utxo can be made available to increase capacity, it actually offers a way for managing load.
+
+I believe I have made one of the first operational utxo smart contracts, CC or otherwise and hope that there will be many more developers joining forces to create more foundational CC contracts. Feel free to contact me for feedback on the type of CC contract you want to make. I have not documented all my notes and it could well be I already sort of know how to implement what your want your CC contract to do. Just only so many I can actually make time to code and debug.
+
+Our testing cycle went a lot faster than expected as the bugs found were few and far between. Considering the scope of the assets CC and the realtime response aspects of dice CC, this was quite unexpected. I can only attribute it to the fact that CC validation is just the final validation on top of all the standard bitcoin protocol validations. Not having to worry about double spends is sure a nice luxury, though dont get too complacent about chain rewrites! It is possible to wait for information to be divulged and then reorg the chain to take advantage of this knowledge in a chain which is rewound.
+
+Yes, blockchains are complicated.
diff --git a/Chapter 13 - different languages b/Chapter 13 - different languages
@@ -0,0 +1,4 @@
+Chapter 13 - different languages
+The current codebase is integrated into the komodod codebase, which is C/C++. However, it is possible to use different languages and integrate into the C/C++ as zcash has shown by using the rust language for some parts of the zcashd.
+
+I think any language that is compiled and can create a linkable library while being able to call and be called by C/C++ functions can be used. If you are able to make such a language binding for a simple CC contract like faucet, this will be good for a 777 KMD bounty. Of course, you need to be the first to submit a properly working pull request.
diff --git a/Chapter 14 - runtime bindings b/Chapter 14 - runtime bindings
@@ -0,0 +1,4 @@
+Chapter 14 - runtime bindings
+Once build time linking works, then it is one step away from being able to do runtime linking, ie. dynamically linked libraries. There will be some work required to prevent duplication of eval codes and making sure it is a valid version of the CC contract plugin, but these are issues that have been solved before and I dont see any reason they cant be solved for CC contracts.
+
+This would open up the door for quite an interesting ecosystem of CC plugins that blockchains can subscribe to.
diff --git a/Chapter 15 - rpc based dapps b/Chapter 15 - rpc based dapps
@@ -0,0 +1,10 @@
+Chapter 15 - rpc based dapps
+Ultimately, I expect there to be so many new rpc calls (one set from each CC contract), that virtually any dapp can be made with rpc calls. We are just at the beginning now, but it is just a matter of time when we get there.
+
+For now, we just need to keep listening to what the market wants as far as dapps go. Then make a new CC contract that enables doing as many of those as possible.
+
+Repeat...
+
+Imagine the scope that will exist after a year or two of continuous new CC contracts being created, along with all the rpc based dapps. I have seen some automatic GUI generators and it could be that for most cases, there can be a special GUI that not only create the dapp's GUI, but also all the rpc calls that are needed to make it work the way it is customized.
+
+This codebase and tools in between the GUI and the rpc level will be a very good area for new initiatives.
diff --git a/all_chapters.md b/all_chapters.md