├── .gitignore ├── assets ├── dag.png ├── dag_bx.png ├── demo.png ├── fastsync.png ├── roots_0.png ├── roots_1.png ├── babblelogo.png ├── dag_lamport.png ├── dag_rounds.png ├── round_algo.png ├── dag_frames_bx.png ├── babble_network.png ├── strongly_seeing.png ├── fastsync.xml ├── roots_0.xml ├── round_algo.xml ├── strongly_seeing.xml ├── dag.xml ├── dag_lamport.xml ├── dag_rounds.xml ├── dag_bx.xml ├── dag_frames_bx.xml └── roots_1.xml ├── vm ├── image1.png └── image2.png ├── dapps ├── image1.png ├── image2.png ├── image3.png ├── image4.png └── image5.png ├── demo ├── image1.png ├── image10.png ├── image11.jpg ├── image12.jpg ├── image13.png ├── image14.jpg ├── image15.jpg ├── image16.png ├── image17.png ├── image18.jpg ├── image19.png ├── image2.png ├── image20.png ├── image21.png ├── image22.png ├── image23.jpg ├── image24.jpg ├── image25.png ├── image26.png ├── image27.png ├── image28.jpg ├── image29.png ├── image3.png ├── image30.png ├── image31.png ├── image32.jpg ├── image33.jpg ├── image34.jpg ├── image35.jpg ├── image36.jpg ├── image4.png ├── image5.png ├── image6.png ├── image7.png ├── image8.png └── image9.png ├── gossip ├── image1.png ├── image2.png ├── image3.png ├── image4.png ├── image5.png ├── image6.png ├── image7.png ├── image8.png ├── image9.png ├── image10.png ├── image11.png ├── image12.png ├── image13.png ├── image14.png ├── image15.png ├── image16.png ├── image17.png ├── image18.png ├── image19.png └── image20.png ├── attacks └── image1.png ├── quantum └── image1.png ├── testnet ├── image1.png ├── image2.png ├── image3.png ├── image4.png └── image5.png ├── architecture ├── image1.png ├── image10.png ├── image11.png ├── image12.png ├── image13.png ├── image14.png ├── image15.png ├── image16.png ├── image17.png ├── image18.png ├── image2.png ├── image3.png ├── image4.png ├── image5.png ├── image6.png ├── image7.png ├── image8.png └── image9.png ├── Makefile ├── quantum.md ├── installing_go.md ├── attacks.md ├── demo.md ├── storage.md ├── gossip.md ├── dapps.md ├── contrib.md ├── distributed.md └── vm.md /.gitignore: -------------------------------------------------------------------------------- 1 | _build -------------------------------------------------------------------------------- /assets/dag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/dag.png -------------------------------------------------------------------------------- /vm/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/vm/image1.png -------------------------------------------------------------------------------- /vm/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/vm/image2.png -------------------------------------------------------------------------------- /assets/dag_bx.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/dag_bx.png -------------------------------------------------------------------------------- /assets/demo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/demo.png -------------------------------------------------------------------------------- /dapps/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/dapps/image1.png -------------------------------------------------------------------------------- /dapps/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/dapps/image2.png -------------------------------------------------------------------------------- /dapps/image3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/dapps/image3.png -------------------------------------------------------------------------------- /dapps/image4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/dapps/image4.png -------------------------------------------------------------------------------- /dapps/image5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/dapps/image5.png -------------------------------------------------------------------------------- /demo/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image1.png -------------------------------------------------------------------------------- /demo/image10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image10.png -------------------------------------------------------------------------------- /demo/image11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image11.jpg -------------------------------------------------------------------------------- /demo/image12.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image12.jpg -------------------------------------------------------------------------------- /demo/image13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image13.png -------------------------------------------------------------------------------- /demo/image14.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image14.jpg -------------------------------------------------------------------------------- /demo/image15.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image15.jpg -------------------------------------------------------------------------------- /demo/image16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image16.png -------------------------------------------------------------------------------- /demo/image17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image17.png -------------------------------------------------------------------------------- /demo/image18.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image18.jpg -------------------------------------------------------------------------------- /demo/image19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image19.png -------------------------------------------------------------------------------- /demo/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image2.png -------------------------------------------------------------------------------- /demo/image20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image20.png -------------------------------------------------------------------------------- /demo/image21.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image21.png -------------------------------------------------------------------------------- /demo/image22.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image22.png -------------------------------------------------------------------------------- /demo/image23.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image23.jpg -------------------------------------------------------------------------------- /demo/image24.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image24.jpg -------------------------------------------------------------------------------- /demo/image25.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image25.png -------------------------------------------------------------------------------- /demo/image26.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image26.png -------------------------------------------------------------------------------- /demo/image27.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image27.png -------------------------------------------------------------------------------- /demo/image28.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image28.jpg -------------------------------------------------------------------------------- /demo/image29.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image29.png -------------------------------------------------------------------------------- /demo/image3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image3.png -------------------------------------------------------------------------------- /demo/image30.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image30.png -------------------------------------------------------------------------------- /demo/image31.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image31.png -------------------------------------------------------------------------------- /demo/image32.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image32.jpg -------------------------------------------------------------------------------- /demo/image33.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image33.jpg -------------------------------------------------------------------------------- /demo/image34.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image34.jpg -------------------------------------------------------------------------------- /demo/image35.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image35.jpg -------------------------------------------------------------------------------- /demo/image36.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image36.jpg -------------------------------------------------------------------------------- /demo/image4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image4.png -------------------------------------------------------------------------------- /demo/image5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image5.png -------------------------------------------------------------------------------- /demo/image6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image6.png -------------------------------------------------------------------------------- /demo/image7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image7.png -------------------------------------------------------------------------------- /demo/image8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image8.png -------------------------------------------------------------------------------- /demo/image9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/demo/image9.png -------------------------------------------------------------------------------- /gossip/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image1.png -------------------------------------------------------------------------------- /gossip/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image2.png -------------------------------------------------------------------------------- /gossip/image3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image3.png -------------------------------------------------------------------------------- /gossip/image4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image4.png -------------------------------------------------------------------------------- /gossip/image5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image5.png -------------------------------------------------------------------------------- /gossip/image6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image6.png -------------------------------------------------------------------------------- /gossip/image7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image7.png -------------------------------------------------------------------------------- /gossip/image8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image8.png -------------------------------------------------------------------------------- /gossip/image9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image9.png -------------------------------------------------------------------------------- /assets/fastsync.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/fastsync.png -------------------------------------------------------------------------------- /assets/roots_0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/roots_0.png -------------------------------------------------------------------------------- /assets/roots_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/roots_1.png -------------------------------------------------------------------------------- /attacks/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/attacks/image1.png -------------------------------------------------------------------------------- /gossip/image10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image10.png -------------------------------------------------------------------------------- /gossip/image11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image11.png -------------------------------------------------------------------------------- /gossip/image12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image12.png -------------------------------------------------------------------------------- /gossip/image13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image13.png -------------------------------------------------------------------------------- /gossip/image14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image14.png -------------------------------------------------------------------------------- /gossip/image15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image15.png -------------------------------------------------------------------------------- /gossip/image16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image16.png -------------------------------------------------------------------------------- /gossip/image17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image17.png -------------------------------------------------------------------------------- /gossip/image18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image18.png -------------------------------------------------------------------------------- /gossip/image19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image19.png -------------------------------------------------------------------------------- /gossip/image20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/gossip/image20.png -------------------------------------------------------------------------------- /quantum/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/quantum/image1.png -------------------------------------------------------------------------------- /testnet/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/testnet/image1.png -------------------------------------------------------------------------------- /testnet/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/testnet/image2.png -------------------------------------------------------------------------------- /testnet/image3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/testnet/image3.png -------------------------------------------------------------------------------- /testnet/image4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/testnet/image4.png -------------------------------------------------------------------------------- /testnet/image5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/testnet/image5.png -------------------------------------------------------------------------------- /assets/babblelogo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/babblelogo.png -------------------------------------------------------------------------------- /assets/dag_lamport.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/dag_lamport.png -------------------------------------------------------------------------------- /assets/dag_rounds.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/dag_rounds.png -------------------------------------------------------------------------------- /assets/round_algo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/round_algo.png -------------------------------------------------------------------------------- /architecture/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image1.png -------------------------------------------------------------------------------- /architecture/image10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image10.png -------------------------------------------------------------------------------- /architecture/image11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image11.png -------------------------------------------------------------------------------- /architecture/image12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image12.png -------------------------------------------------------------------------------- /architecture/image13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image13.png -------------------------------------------------------------------------------- /architecture/image14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image14.png -------------------------------------------------------------------------------- /architecture/image15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image15.png -------------------------------------------------------------------------------- /architecture/image16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image16.png -------------------------------------------------------------------------------- /architecture/image17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image17.png -------------------------------------------------------------------------------- /architecture/image18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image18.png -------------------------------------------------------------------------------- /architecture/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image2.png -------------------------------------------------------------------------------- /architecture/image3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image3.png -------------------------------------------------------------------------------- /architecture/image4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image4.png -------------------------------------------------------------------------------- /architecture/image5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image5.png -------------------------------------------------------------------------------- /architecture/image6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image6.png -------------------------------------------------------------------------------- /architecture/image7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image7.png -------------------------------------------------------------------------------- /architecture/image8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image8.png -------------------------------------------------------------------------------- /architecture/image9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/architecture/image9.png -------------------------------------------------------------------------------- /assets/dag_frames_bx.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/dag_frames_bx.png -------------------------------------------------------------------------------- /assets/babble_network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/babble_network.png -------------------------------------------------------------------------------- /assets/strongly_seeing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Fantom-foundation/fantom-documentation/HEAD/assets/strongly_seeing.png -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # Minimal makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = python -msphinx 7 | SPHINXPROJ = Lachesis 8 | SOURCEDIR = . 9 | BUILDDIR = _build 10 | 11 | # Put it first so that "make" without argument is like "make help". 12 | help: 13 | @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 14 | 15 | .PHONY: help Makefile 16 | 17 | # Catch-all target: route all unknown targets to Sphinx using the new 18 | # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). 19 | %: Makefile 20 | @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) -------------------------------------------------------------------------------- /assets/fastsync.xml: -------------------------------------------------------------------------------- 1 | 7Vlbb9s2GP01BrKHFSJ1sf3ouHUGtBuKGEO3R1qiLSKU6FJ0HPfX9xNF6kbFyRInXS56MMRD8XbO4aeP8sifZzcXkmzTP0VC+Qh7yc3I/zjCeBoi+C2BQwUEU68CNpIlFYQaYMl+UAPax3YsoUXnQSUEV2zbBWOR5zRWHYxIKfbdx9aCd0fdkg11gGVMuIt+Y4lKK3SCxw3+B2Wb1I6MomlVsyLx1UaKXW7GG2F/ra+qOiO2L7PQIiWJ2Lcg/9PIn0shVHWX3cwpL6m1tFXtFrfU1vOWNFf3aYCrBteE78zSR/7sL5ATwJmZojpYWmC22/J2l/EvbE05y6F0vqWSZVRRCTXcwF8b7HyfMkWXWxKXTffgF8BSlXEoIbgFDRWBJrIuc062BVvpUT1AJI13smDX9JIWlVVKVOxUOdK8tkAJFkqKK8C4kHrKvqcvqFkzzlv4Ql8lDsMbA6LyOcLZJodCDAzq6buUGpavqVT0pgUZii+ogKXLAzxia63cZjtgz5T3jbmQxdKWsQILEmPoTd13IyrcGF2HNfaPaAyrizgMdr6ScLdR9XrfVX+06gEKfqHqY0f15SGPL+n3HS3U2edc7PPfHKlbApXrZBARZ4aZlVBKZJpsItWsDLKA5kKbQWMLVk5GC0LzxD6x4iK+so8YyidDmkX6qmts3EUDat0qTiF2Mqad0EaTTqh31WqpERneJeVEgfO675UBMUxvXwWDiTTbvbvbo6gnZzVL06gdnHv9BFEvbEx6HQGlG6qcjrQ16hXeyy12yo5diq3IC3pWhwkbJcraLyxjytbACHXlizUW+Eke/inH+hBiW/5Xl/HYt0ArzOlJJaRIaWK6HHTdgFmfw4hB5H8IOxby8eRhXkRjfLyjE3oROV5ckEIthNwTmdgI9mI99n8yCBp3I4w/DR8cqvpO63d1QoO4Weu6bRATs861eBi68xaSZLS6XeaQZqRCvVj/vLoY1c2Sggg9zIIQoXoWdLo6oQUn7vtSEQW3szKrJqsVZKkbx2L6ZKhl8O5OkR2TTPDK1ybpZbVJSCdJcCSr5XTdZPZOAnsv4W2DXm6Dw4GcFg/ktPgEKS2aHiN9TlScAul/b09M+zQa+2SAdoqA+PEvod1/TtrxQG74Fr0e+s9JeuCQfmKGbzsjm+9Vz8FwHaD7B5zOCdklODwBwW4s+cjW6/pg7P0OhxmSlSSaryLefzsDOWoBTeqYJCabaKthoB7x/eQkY0lSDjLogK5HhnPRx2k4nnY1nAYDuyR6ol0SvsFdUmfWd+ySKHw8wcgNQxdUzfI4FVLn19+YSnV2XR7I7vyU+Gr3wKSjUOAN7AH/ifYAcvcASGSPOe+ytGTBAxvnqWSxIe9VhyYU9U9c9wtN4SlCk0tw6zORc/p/w/sAd9/QwRgNbAP0RNHJ/R/ikhZKSHrW+hLzrkylzNCbHZ9GGSg2fytXXzyav+79Tz8B -------------------------------------------------------------------------------- /assets/roots_0.xml: -------------------------------------------------------------------------------- 1 | 7VxNc6M4EP01Pm4KIcBwjD3ZncvWpiqHTY4YZJsaDB6MY2d//Qok8SHJMckgMTE4h5gGhNSv3XpP6mIGl7vzX5m/3/6dhiiemUZ4nsFvM9MEhmfhf4XljVhsBxDDJotCelFteIr+Q+xOaj1GITq0LszTNM6jfdsYpEmCgrxl87MsPbUvW6dx+6l7f4MEw1Pgx6L13yjMt8TqmvPa/h1Fmy17MnA8cmblBz82WXpM6PNmJlyXH3J657O26EAPWz9MTw0TfJjBZZamOfm2Oy9RXPiWuY3c9+eFs1W/M5TkXW4wyQ2vfnxErMdlv/I35otyNKi43pjBxWkb5ehp7wfF2RNGH9u2+S7GRwB/PeRZ+gMt0zjNyrth6Kwc28Fn1lEcN+zYJWYQFPY0yWkAgOIBfhxtEnwQ4BEgfPGC9hBlOTpfHCWofIdjEqU7lGdv+BJ6g0u9TaOxOj7V2AKGyLaBq0NtPg2nTdVy7VL8hXpV7mEoePjhtei2adwbgq/xEPP3HJqkCeJ8SU3MbTFaFy0U7opwPN9T8y4Kw+IhUvzaCPOA6PG/I3G/2YP7LcH9TyheP5Kum46/KxyQrA77cqSGYIL3IwUJGiJIc0Ug2ZIs5Pw8Fklw0fw2DiCA5XJIAAEJSxESzoRECwmvjYQp/iZUITEXkPgn36KMZq7xpiUJBKrSkquaHK1c27INCTlyA6SNHFURPAQ78i6yo8Vo2FEXAFTRIya4Jn70YZh0EiQApnm5AQU0hmNIQCaZxwzFcBQJiNp6nBxJSE0aSRIQFXbPLMlz5tCXLCEhENporoklWcaALAmIApnRpOVoaFIXBJTRJFEXTzSpG0xaaZIomsc8N1vOgDRJJp7HDMWANEkU2eOkSUJq0kiTWBvqaJJTfiSLSXbxp4kmcat1wBEzjjKWZIoiudpqA2OJ8Q4AqCJJLKInkvRhlFwRJWWJSBTNGIg4pwOdFUUVLHfUszRcr5Htea0pfFP8Lzaxyd34waQBcmIsUPK7dcA1tc3skt3tTlgCL5BhuZiwbLM0UyNhlmyCj5Ol8cUiEgyU5UbZ9jfndZSE90WFWe3NTqSMnGHFZOCi61AoVKZxjsO9SY9ZQK+iHcz9bINanhD923CgLXEgs2Uo9vPotd0LmVfpEx7TqEw1cvgswOFCOk9vqqER2gEWbMeBxTVEhiw0VGJcjbob7LJlA12wo3OUPxe/pjubHr3Q39bnAsK9DfC5JMB3pUfwle/yO4GLVmtRmIU+ctdD7fIDpgK0KLN3tvlHo8y6IKBKmsFpm//TMEm2GVTxDyjd5p/4fF91AjKdrYrPQ3E1ZMwL4HydgCnZFlIGxVQnIM9tMhCU5bYOdQJfi2Rzqus2iDdsNwR5+tcf8Yayqv9eibdrrqBsRyS0kRtamog3v+mkk3dDcT2jqhsZDe/uAIAy2i0uLEy0uxtKOlm3tFThKusOoL8KDZF1L8fOuvmyE52kW1xo6AKl7wUWWkkEFBg9lG3WDjSydtbu6Fk7nxplIKjKjZZsRWJ41o49l72RU65lM0N59s7zHGZ4RFmEh1xQuV8g+zK2b93EHotlcz9vhm7/bN+SLYdoCyQWLqAVKpfCpI47F5jNyLvz5uy4n9BiOa4ZWqTY+6uHlkYhackm/V6FpFF+RCFJX+0xSGmdTh1pi1NxVVkn+vpGp+Hr/lclI21xEp5kZCeQNKpIWzbBNaUHUQ7Pz89fWVMUx40EuFzSxNgDdHwhnUbZaF+riSQIvby8TNh1KpzTqRNtcWNhnDqRLyrW+QKfLhVUcRztD5e88x79qiJVgkjXIOeQ6yPm2eo69ffcFtzN5oSmu2Ef7u5Qs3Tr7vY0uruDwPiYdq38dF27vp+1rwvOoYRk9WoRlo74+s2uSnLebkddGagjqpwJ5mswz3tCmQ8XhTD3vqRZLQ98Hma25AQay01/GHcGsHpdb/qtYqW36mAh6HoMFpmq+x2Dxeg3TrxbiBN4Yef/l8MEH9av6CWX1+9Bhg//Aw== -------------------------------------------------------------------------------- /quantum.md: -------------------------------------------------------------------------------- 1 | **Quantum Resistance** 2 | 3 | Cryptographic protocols are susceptible to attack by the development of 4 | a sufficiently large quantum computer. Of specific interest to 5 | cryptocurrencies is how this relates to proof-of-work and more 6 | specifically, the elliptic curve signature scheme. Optimistic estimates 7 | state that this can be broken by a quantum computer as early as 2027, it 8 | is therefore important to adopt a post-quantum signature scheme. 9 | 10 | Signatures are often based on the Elliptic Curve Digital Signature 11 | Algorithm secp256k1 curve. The security of this system is based on the 12 | hardness of the Elliptic Curve Discrete Log Problem (ECDLP). 13 | 14 | How quickly can a quantum computer compute the Elliptic Curve Discrete 15 | Log Problem? An instance with a *n* bit prime field, can be solved using 16 | 9n + 2 \[log2(n)\]+10 logical qubits and 17 | (448log2(n)+4090)n3 Toffoli gates. Bitcoin uses 18 | n=256 bit signatures.[1] 19 | 20 | For 10GHz clock speed and error rate of 10−5 , the signature is cracked 21 | in 30 minutes using 485550 qubits. [2] 22 | 23 | So if all Elliptic Curve Digital Signature Algorithms are susceptible, 24 | then how can you implement a quantum proof solution? 25 | 26 | 27 | 28 | In blockchain context we care about signature and public key lengths 29 | (since these have to be stored to fully verify). 30 | 31 | Hash based schemes like XMSS have provable security. Grover’s algorithm 32 | can still be used to attack. DILITHIUM at 138 bits require time 33 | 2125 34 | 35 | A truly quantum proof cryptographic algorithm does not currently exist. 36 | Instead, the architecture allows for multiple cryptographic 37 | implementations to be plug and play usable given the modular 38 | architecture design. Since we aren’t focusing on tightly coupled 39 | architecture, it means we could implement ECC, XMSS, and DILITHIUM. 40 | 41 | [1] M Roetteler, M Naehrig, K.M. Svore, and K Lauter. Quantum resource 42 | estimates for computing elliptic curve discrete logarithms. 43 | arXiv:1706.06752, 2017. 44 | 45 | [2] Divesh Aggarwal, Gavin K. Brennen, Troy Lee, Miklos Santha, Marco 46 | Tomamichel. Quantum attacks on Bitcoin, and how to protect against them. 47 | arXiv:1710.10377, 2017 48 | -------------------------------------------------------------------------------- /assets/round_algo.xml: -------------------------------------------------------------------------------- 1 | 7VxLc+I4EP41HJeyLMuPI8m8LlOzVTlscnSwAq4xmLWdhOyvXxkksB4wToIag53DDLSFsPrrbnV/ajPCt4v19yJezX/mCc1GrpOsR/jLyHURJhH7r5a8bSUhDraCWZEmfNBecJf+R7nQ4dLnNKGlNLDK86xKV7Jwmi+XdFpJsrgo8ld52FOeyd+6imdUE9xN40yX/pMm1Zyvwg328h80nc3FNyOfL/gxnv6eFfnzkn/fyMVPm7/t5UUs5uILLedxkr82RPjrCN8WeV5tXy3WtzSrdSvUtv3ctwNXd/dd0GXV5gPu9gMvcfZMxR1v7qt6E7rYrIbW450RvnmdpxW9W8XT+uorQ5/J5tUiY+8Qe1lWRf6b3uZZXmw+jZ3NH7vylGZZQ861wuT5suIGgOpxcZbOluzNlK2AssE3+pL4Kl9oUdF1Q8SX+J3mC1oVb2zIWjYrbo2uw9+/NrDlonkDViGLuTXNdhPvNcpecKWaFYwNCvYz9gU3SfoiKdr/97lG/YatqfqLa2HCRmT0qdpfZa9m/P/NLOUqXgrZ3d+bT/jxokZl+ViuGgPZjTbHNsSbGxFSBfz6Zo4hvMyXVAGXiwSOm9vHNzVYKXOwCRcv0iSpv8RoULLJqRYCYxCewSDcExiEB2gQ9/f3A/wG+Mn54CeA8P+q5rQotzFhMII/xQAMZwS+ZSN4LMAhLrYa6jjGBA7jQMN4YkHtuyypW3rHst4xYIAN+5HR4vOltNGQ0nZxO2thEbZ8ToTZIak9pwEEZzQABGgAQ1r7rjgAmNciE500JLYQKANmtsjEaSl6Z59IV+Uh9TTgiMvVlsB9Ste1wvR8K3Qfse/r+VZCaJh4R/ItgdxJ1O1K6o50bQeerm0h+5S2TYSRqu1lMqlZ7731Hktg/c3f7ooguJFBlUxjxdt9bcZjIt4+8LEH1Vrmz8WUStl4FRczWsnmQxOJg9d131AuMZiykBU0i6v0hUr3YNI4/4a/85Td8KESEUeKh2xXwz+0h02bx1fm8ZR5tirQ5tnAv1t0O4vQOSQbga+jpSXyIlnRkGmOibi5vuLSJUjeXACLS6TzJkN1eX6va2MS1rzOROkM1SWwAURnNABIxmmoLt8VBwCrSzEHiBlMJpMO2EA3i0/NCACLT5FxXWY5JBLIZj1E+PbWlXoIy+B+uCBiRfLYwZ4XugEJfdcJpGlZGj+upX4Y+YSgQBTYpy+XDC04txZctaPlkquwwpDlkrHXRfVVZvV3/G1JZwu20q970U3DladZXJbp9ITevE6re36tfv2wc+xWvtwxv8UOGe/dyfVkwgphb7y/hnCoMFNtnRor0WFHe/zBbxmI8Vtj2KoeUB5ZjUKnIN4zcfC+lPHivvaWur2DDwcRU9/O9VX+uMUZkq3K33pXzFD52zIJaxsIJBk0VP5mA/DO2Cxr7OYZKv9OxAHIyh+SABoq/3cYAWDlL+wN6Nj5w/nYCY+dceQpWbCubmxQNz6Fuk0tPRdDtIh8vUm0CK10pGBTn0L4MNGyK+ntHz0LlqZhFF8sBL+Ocik4PN/RM27TdHOxXIrvdco1PcU1yQc9k80zZlbjRIT/K2+evvHqiZkUL5TX4nnHb1kZfmoiBbcgUrq7rXRsC/FQNPYiJ0A+Ch0cIFdOF3a9Te+2W3SMug8diWgUx/MWdpt+tNt4keJykI8nD+02XSy225iEtUxjaLc5vwGQMz7Ng4d2m66YgRYHAEk3MS+IGTw8PHTABrpJumlGAEi6iWPkC03XeQLZkXRdZU8/zPgQVyYikFqgni4H93Te4asFz+so40Oc8zE+Xovq5yyuJ7gefkmwPW2dMgg65ZS+Q8yZVoedkuiNVT/icr7ddOvzq56kR8iTAyoyuKdvyT2JTmTx+tbZFDU9RUA8vwOBgB4gf3EEpKRz96qnkGBASFr8+sqVPRrMSnVJ3eKMCODRYKIX6r3cBlzfVbeBMQGzeV+vk3u4EWgYoAASA71ZQWwFNbPQVwwwKAZtuv2vK/bjQI79+kZrK/T7evbZy9CPQ/l5BMD009fTzx7GfRUA7MEBoJ9d9jDoqwAQQAA+f1LIeT/tjGADIBDr31HuUXvi3tMrC2s/UPv5I8AB2cMHOtrP0iIwZIOL/PEuTbcGBI6cn8lpceiDpWnB9RC1n4KAKC3KkQ6BrU0quBae9qQAIPErbBAIHOZpLytPOy0CGBABU5ffdQd9EspNq66jq9ta1Nfz4n3U75PJR8rRKmTQ0TNYEfbH43FvETD0j9lCINR58V8DAqbmLWsIXGoHidIaIvePREFrDGA6SAKh1t1Wo0zRtoNEnQgRZaLTdZCEekbwzYJL2ivAP+WUgSMrGjtwBXjY5oj88pwSd80po/DynNLEul13mu6H8vYYwh2hRXp+0ktuxo/kQ8wI7ghNMNz95mZUABCCO8IR1Gi/uRkNAQzHT0b9I+QD9RlzRzd4a1H/GCPfI5MPQiU/ggw6hyn5HjEDGgJYL0KsIXCYku8zAoZzWGsI9I+S9wUfdY6wf4yS71Wuqf5ECGDYHyh5EwKAYX/3fFS/474Ggb24z94Wed3/tKeE2CLnP/OE1iP+Bw== -------------------------------------------------------------------------------- /assets/strongly_seeing.xml: -------------------------------------------------------------------------------- 1 | 7V1Nc6M4EP01vm4h8X3cyezMXqZqq3LY3SMxsk0NMSlCEmd//WIbESRwBnBLajCuHIKMBe7X3Wo9PeSVffd4+J5HT7sfWczSFbXiw8r+uqKUeJSujn9W/H5uCULn3LDNk7g66aPhPvmPVY1W1fqSxOxZOLHIsrRInsTGdbbfs3UhtEV5nr2Jp22yVLzqU7RlrYb7dZS2W/9O4mJXfQvqf7T/yZLtjl+ZeOH5nYdo/XObZy/76noram9Or/PbjxHvq/qiz7sozt4aTfYfK/suz7Li/N/j4Y6lR9tys50/9+3Cu/V952xf9PlAhdNrlL4wfsen+yreuS3YPv79aNLyaJ/ty8Yvu+IxLY9I+e9zkWc/2V2WZvnpbNs7vep3uPWO526yfVFBXeJsfzlficUtKD5uvmp6zl7yteAi1bf5zrJHVuTv5TlvHzi5lXF3DYh4W87SqEhexUtGlbts6+7qK/yVJeXNUOsgdlP5teNYYg/nO60+1LT75/1QS+qniPItK1r9lP80vvRH0wnVboTt6SFMTSJMbCCI5Y4UYuxMD2NiEuMQCOJQG8Lu5BAOjQaxDxXEvjaIvR4Qp2lZAR2hfdslBbt/ik7WfiuLMBHu6PnpXBZtkgOLj5gmadpAvyxI6HrdgXWUJtt9ebAuoWV5l+PE3oPnerVbvLK8YIfPHaPtBdUHnAsoNZyEdjgJtS77gwDAJ9b2dVo7WLOR1n4IXMe1YKwdmLM26VOFQJmbkdhl/ihzh55vR0DOTTyD9u5TEUDZu7R2EDuj7B3QB9uDsjc1aO8+8ygoe387vfrYW4FV7VCjVadR9ZxLgKYjLHOX/mUP6VP3DAK5rlBEkO0OkEso8/d/yiPrN5cf/ssd4kLJNEXHgKItpAmPa6tzCzLXjCqVYTbRmFD7VL2qYu36eGpOL4OOEFs4hWEhFtxG5jXqFvJIWtdP16ZeOR8A+oU119TrXMBCR+oNJ516hYBaVmAGxRPtE0+qpjGf5Vl2SIrGW+XR8Z0rSH0bm7NIAe96QMmXKHOWPmPyJHOvXPa6+nIvt+GEeITAZNQoKmVtuR/AFAu+yg1Uyl5OsbDTIZ6Q0PiQlHl9F8aHfHXDdJ8CbZKZV16IoL7G1DsNaUIzbJaF66HJF5ymn1ryxeZF00u+WtUPccSCzbj1eG8dsIeNEjaC2hrTskkiWFdYYgrB1krJWJpCDmVAiRlCpWgTTq8WX/8ywPRADEZFaeSiXIT1mABy/yyqB2Qbakld7kglyAh1EwLIDjKQwRgPnYpgcN0ELMi+jQxkG2pqJXekEmStMlUcomCTqmBXJ/2ORBZsUhfs6iTdkOiCbYO6YH7pW9IF2wZ1wbycnR+pLFtVp5bCoz2sqrn0aXJ/yyQG4nEok3TEZ6zyFB0AjqrQpwD2+lAVk8ydJiXAHjg3UNeiw3VovAC+EFLCdLJjgXvhESDCzCSPcG2exeYA8vg4Wu2rUe7r6eQY9OZZg3pfD1xcD1yjLqspAKEDLuo2pextDrWclMHtLlDSXo3aXl7DzDDTGlT3+n04FiQVbTOkuDfgCSlV1atC4a9P55iBebbF7S5QKjONMjNf5z4kevlYgyJf36So5Mop5LJMDRFWJkklGAXwACqKsw6o3WiS2fkGRcAmVcA+uAp4SNiqCE30YThaB6xRCOwjpK4EXTdFBrIDRV3JHakcsk1SVz1ADjxkILtQa+hyRwpB5qwMWpBDZCA7UBSI3JFKkMH5LwWPWBqLWnkSFIyNWn2zqYD2AHRmol/HoOg30EkKIRH9OgZFv4FOYQ8S0a9rUPQb9GFnZib6rfUSJuytk8bQSjLLVtUpqAjAyYra3wYv89VOvuouf4RdWJaJDEBJZJKSuHKFAZ0DwNEV+sTAQR+6YpI5Va7EdIqBOX6Ypo4C0+d2hNPCGQDsdQXOGQwYTAds/TtooMXmGPL4OFoM3Mqz6sTAnFufYZ41KAYOEW6tImxWRZGFzhRXVMI+tMbkpGicrMHtLlBi4FamVScGDnWyMmYrWo1i4BDhrihC6LjYQkdV9apQ9BuCU0EYMi3PqrjdBUpWJruLyo19Z7unuryqoFP0GyIUkAihEyALHXkFeTzvqm8pmvCu0REFveWDv6IQuvQoqP1oiimYWDo3wkEi7ZWB0intJRY1GbgqghN9II7W9rZICnXaXmIhpKLEvdSxPWnsQXFRckdKx22TZFQvmLEpBX2oZXG5I6UwI9/pl/AfIkcDswfFd8gdKYUZIaslwEyxPXfjQ0225I6UwnyDu/16BoW/xLrB7X49g8pfYt3gfr++Qekv0fpbvki0v75B7S+Z7+/Wy2bV+uvJBJzOgGWbl/kMSAVEJrzpLz4XgGMu9Al96xnj/BKoXHnpVPoSAs4U1DXS4Mcn6sLsQlSJU0urK9QWWgEi1Ca89S8+F5DHydFy31a2VSf3rdn2GWZbg3pfQhBuoSJGz7LKAhE94BqYAYMqiDpi0FDM2RvkngQlBm7lYXVi4LrKmWEeNqgGJrQPG2MyD/NviSd6VBWyCvXAhKN6I3mYdGwPjNCToHRqsiep1KnR2W4QLC9D6NQKEwouR1HHPohRtSxsQ0SVSfLJQH7ueGYOnydNMz/f4BbBMlBadcQU/FmrIaGrJDzRR+JoIXGL+wATEpeHeZYVzdPLcNr9yGJ2PON/ -------------------------------------------------------------------------------- /installing_go.md: -------------------------------------------------------------------------------- 1 | 2 | # How to: Install Go 1.9.1 on Ubuntu 16.04 3 | 4 | Introduction 5 | 6 | Gois an open source, modern programming language developed by Google that uses high-level syntax similar to scripting languages and makes it easy to build simple, reliable, and efficient software. It is popular for many applications, at many companies, and has a robust set of tools and over 90,000 repos. 7 | 8 | This tutorial will walk you through downloading and installing Go 1.9.1, as well as building a simple Hello World application. It’s an update/edit of my other story “How to: Install Go 1.8 on Ubuntu 16.04” 9 | 10 | ## Prerequisites 11 | 12 | * One sudo non-root user 13 | 14 | ## Step 1 — Installing Go 15 | 16 | Let’s install go1.9.1 on your PC or server 17 | 18 | If you are ready, update and upgrade the Ubuntu packages on your machine. This ensures that you have the latest security patches and fixes, as well as updated repos for your new packages. 19 | 20 | sudo apt-get update 21 | sudo apt-get -y upgrade 22 | 23 | With that complete, you can begin downloading the latest package for Go by running this command, which will pull down the Go package file, and save it to your current working directory, which you can determine by running pwd. 24 | 25 | sudo curl -O [https://storage.googleapis.com/golang/go1.9.1.linux-amd64.tar.gz](https://storage.googleapis.com/golang/go1.9.1.linux-amd64.tar.gz) 26 | 27 | Next, use tar to unpack the package. This command will use the Tar tool to open and expand the downloaded file, and creates a folder using the package name, and then moves it to /usr/local. 28 | 29 | sudo tar -xvf go1.9.1.linux-amd64.tar.gz 30 | 31 | sudo mv go /usr/local 32 | 33 | Some users prefer different locations for their Go installation, or may have mandated software locations. The Go package is now in /usr/local which also ensures Go is in your $PATH for Linux. It is possible to install Go to an alternate location but the $PATH information will change. The location you pick to house your Go folder will be referenced later in this tutorial, so remember where you placed it if the location is different than /usr/local. 34 | 35 | ## Step 2 — Setting Go Paths 36 | 37 | In this step, we’ll set some paths that Go needs. The paths in this step are all given are relative to the location of your Go installation in /usr/local. If you chose a new directory, or left the file in download location, modify the commands to match your new location. 38 | 39 | First, set Go’s root value, which tells Go where to look for its files. 40 | 41 | sudo nano ~/.profile 42 | 43 | At the end of the file, add this line: 44 | 45 | export PATH=$PATH:/usr/local/go/bin 46 | 47 | If you chose an alternate installation location for Go, add these lines instead to the same file. This example shows the commands if Go is installed in your home directory: 48 | 49 | export GOROOT=$HOME/go 50 | export PATH=$PATH:$GOROOT/bin 51 | 52 | With the appropriate line pasted into your profile, save and close the file. Next, refresh your profile by running: 53 | 54 | source ~/.profile 55 | 56 | ## Step 3 — Testing your go 1.9.1 installation 57 | 58 | Now that Go is installed and the paths are set for your machine, you can test to ensure that Go is working as expected. 59 | 60 | Easy and simplest way: type 61 | 62 | go version //and it should print the installed go version 1.9.1 63 | 64 | Create a new directory for your Go workspace, which is where Go will build its files. 65 | 66 | mkdir $HOME/work 67 | 68 | Now you can point Go to the new workspace you just created by exporting GOPATH. 69 | 70 | export GOPATH=$HOME/work 71 | 72 | For me, the perfect GOPATH is $HOME 73 | 74 | export GOPATH=$HOME 75 | 76 | Then, create a directory hierarchy in this folder through this command in order for you to create your test file. You can replace the value user with your GitHub username if you plan to use Git to commit and store your Go code on GitHub. If you do not plan to use GitHub to store and manage your code, your folder structure could be something different, like ~/my_project. 77 | 78 | mkdir -p work/src/github.com/user/hello 79 | 80 | Next, you can create a simple “Hello World” Go file. 81 | 82 | nano work/src/github.com/user/hello/hello.go 83 | 84 | Inside your editor, paste in the content below, which uses the main Go packages, imports the formatted IO content component, and sets a new function to print ‘Hello World’ when run. 85 | 86 | package main 87 | 88 | import "fmt" 89 | 90 | func main() { 91 | fmt.Printf("hello, world\n") 92 | } 93 | 94 | This file will show “Hello, World” if it successfully runs, which shows that Go is building files correctly. Save and close the file, then compile it invoking the Go command install. 95 | 96 | go install github.com/user/hello 97 | 98 | With the file compiled, you can run it by simply referring to the file at your Go path. 99 | 100 | sudo $GOPATH/bin/hello 101 | 102 | If that command returns “Hello World”, then Go is successfully installed and functional [1]. 103 | 104 | — That’s it-go1.9.1 is installed 105 | 106 | ## Conclusion 107 | 108 | By downloading and installing the latest Go package and setting its paths, you now have a PC/machine to use for Go development. 109 | 110 | Check out the original version from DigitalOcean, this post is a copy, but for the 1.9.1 version: [https://www.digitalocean.com/community/tutorials/how-to-install-go-1-6-on-ubuntu-16-04](https://www.digitalocean.com/community/tutorials/how-to-install-go-1-6-on-ubuntu-16-04) 111 | -------------------------------------------------------------------------------- /assets/dag.xml: -------------------------------------------------------------------------------- 1 | 7V1Nc6M4EP01uabQBwKOk8zs7GGnaqty2NkjGxObGWJShEyc/fWLbYSNkFWKjZpGmxxSRsaAu9+Tup9a8hW7fdx8rdKn1bdykRVXNFhsrtjnK0o5Y83/bcPbviHiwb5hWeWLfRM5NNzl/2ZtozztJV9kz70T67Is6vyp33hfrtfZfd1rS6uqfO2f9lAW/bs+pcts0HB3nxbD1r/yRb3at8Y0OrT/nuXLlbwzEcn+nX/S+5/LqnxZt/e7ouxh97d/+zGV12q/6PMqXZSvR03syxW7rcqy3r963Nxmxda00mz7z/124t3uuatsXdt8gO4/8CstXjL5xLvnqt+kLbL14tPWpM3Rulw3jTer+rFojkjz8rmuyp/ZbVmU1e5sJnZ/zTvDJ2kf7rl8qe7ba1O+b8sWPX+0z/o1Kx+zunprTng9eCFsTbc6coBsq7IirfNffS+mLRiW3eW6O/xZ5s3T0aDFbdxepkVtKIL+FfaP3n7o2Krm65BEuU6dVsusHlyneXH0pQ9NO5/p/cem9R+LUfmP0JEcqF7IoQf5tB5szsTkQRqM5EH1Qg49GE7rQZ6g8iARY3FQgHlQDDz4aeDCOtvUJr+1fn3Ii0JpSot8uW4O7xsvZk37za+sqvMm2PjUvvGYLxbb29y8rvI6u3tKd659bSKrpm0XTGTbBw1MiNheM9sY/d++q/pHDlZH8OAaeNDgNBJ6pjfYORrY+cZfOxO1KwM0dDww9K3HhubTGToZGPqzx4ZW42NAQxObOKkomgTxlDmO7J8+P+2zxod8szVQz/aHlE3jgDGsmChWDIdWpK6sOEGssh+m+15EEqs4iza5s1CF2GR88+BBOCEPhhEfLA8YKh44i9kd8oBYeHAWPIgUkyWANBjGibA0IKho4Ej+c0iCwFMSQI4F1FcjMsCehNp0xw5FMKLpXeT3wtm7cFXOQte7SBf6R4wIkBgTz9DI79AjBsVMDIafGN5oEQoxKOSwOxSDYYlBNcTAJU+oxIiwE4MM5VA/iMEJIDG8MSIhfSuGFM6KzCaqd5jaSi8i6UqcVUa460yYNwqPygPOIzge2ATxLofZZMgN6Vms3FDtjpAb3kSgKjcYYAjKJq7cYZpxg+EKQQeQVjGNkBs2czvz5AZk/DRxeiZ50OMGrlpFFdJd14WXG9wmGpgnNwI4bvCpq67FkBvSs1i5gT+m4t7mG1RTp+WMGxPXs0se9LiBO9/oui7E3PBmjnTADQHIjalXCmjyDelZpNzoui683GDe6rWd0SC4MUFFXo8bmnlShlvDpTPQcG0KzObJDch8Y+pcXKfh4l75OcA0Pm6E/uQbSiU3F3DzGyGdlhuykvuYGyGyfEOt7j5bpwKr7pZP6B83GGAuHk6sU4WafEOaAyk3OP6VD9yffEPhBk0YHDcm1qnkV+/l4sjyDXGi60LMDX/yDXWVqFzTDcGNiXUquUq0xw1c+cZg5ei5MRXcytHQX24A5uKhzejrUqeKh9wIkXNDdl2IuWGjsMySGxxwrYsc5ieLqXTciHBz49y5PzhuCOorNyAXSIqpc/FoyA3pWaTc4OeudwHkhj8arsoNwHlxMfUeiFTDDVwargrpsxdJAnLD23yDye1jALgRTRxTSR70uIE732ByrMXLjYgMndgY8649LKt6VS7LdVp8ObQq+7kduTjb5PX3o9d/y9fr5oG+Hx/Id35kdf3WbrudvtRl03S45x9l+TQSeHRBh21Abo0K62HG2yQPct12ZJMOuOyQNEmeNaYm6pDOLX4GHKz9WTSjcgNw0Uw0cZKn7W9xLZpRIU3xC+eRu9LEboQOjkfo4Do8MaobN3LtTaFoUhpkUyjKpKA4N9tXK/OEyuQRkeCuEO8EEk7hYIcQKyToFmAjQwJh0TUNRJyIMCQR5bKmqturgF5HYSy6U87ESZJcH+4QJcpNeHxNj+4inGHI3Z6L78MQse5LZrC9BTcjKBoFQTQwIiiEQpC7KUhn45GuF0I2bUlCM4bicTBEjBgSQBiSpTwuMTRQHSSCgrMiGk2hLUWGIGFGUDIOgqgRQREUgmymPsbshU4pXe+JhfBPEJPIiCERjIMhZsRQDIUhigVDFyEI11QRic0IIuMgiBsRlEAhyJ3i4mgc0xXFy4wVC4ISM4LoOAgKTQgSARSC3E0+6xHUj6bPw5BG50O2qRoNzBhi42BIGDFEoDDkrmDa0Timy+lDZEoxMSOIj4OgyIggCoUgRBqzfTxNdFk9MhRRM4rCcVAUG1HEoFAEoE+PHA1ptrJiuH4ciZrVaTGOOk2N6rSAUqdjcHV6jH6IabQhbMWtZoVajKNQM6NCLaAU6hhAoR63H9IhiCJDkKpP9307jjzNjPK0gJKnE4fy9MmuxtRBWYFIpvGI17srv2tw/qS7sk2Kw0n3BFpoHmVIkg+JuKZ8jligeLBwCRKQ7fI9RyQ4FH5PBBKnQw8rHOgq6ZHtaN39akpXU3ducZ7600Vqld+IQADQby27BGsoUF3WiwsKc+wSoFXYcXJXDRaQLbCZIxam1VMPR+9TwzQJhMBVaTdHLIBX7Y7RL3CNtv6BhYuxAK1vXjxTp8XBR6xwKQ4cKpTvFZiskfA/Gh0GK66dIYHIHGdmw4MODLhKGWfYLZBglmIj062JxTVGqNICjcLz0KBKC80TukMDnSMadOoCsp+HmmXXAFBqOrr2rIPCxyzExVDAozm+p18IP8DgAgyzlB0p14DhY676YjDMso5TBwZkP340RzDYRI/z2FNF2WKh2+0aYE8VatO9zsKKCoS7YwgjerO9j2LEThiCMKI/GxoqfOaAG+EymzRqnlYE3IZe2OjX87Ciul9XAre5ZuhNtzjY9t3drmfNYVWW9XFY1Nhi9a1cZNsz/gM=7V1bc5s4FP41fs0gCV14jJ1296UzO9OHbR+pITZTYjKYNMn++sUGYZDkhGB0c+uXxDLI9vm+c9WRvECrh5e/yvhx+6VI0nwBg+Rlge4WEAIQRvWfw8hrM4Ij1AxsyixpLzoNfM3+S9vBoB19ypJ0P7iwKoq8yh6Hg+tit0vX1WAsLsvieXjZfZEP3/Ux3qTSwNd1nMuj/2ZJtW1GGaSn8b/TbLPl7wxI+4V/xOufm7J42rXvt4Do/vhoXn6I+VztF91v46R47g2hTwu0Kouiav57eFml+UG2XGzNfZ/PvNp97jLdVWNuwM0Nv+L8KeWf+Pi5qlcui3SX3B5EWj/bFbt6cLmtHvL6Gaj/3Vdl8TNdFXlRHq9GwfFRv9LMkyaSoE8frR3aF0/lur2Kwk4INbnS4iGtytf6mucTCrgV3bYHAB8r0zyusl/Dt4xbMmy66bp3+KfI6g8Dg5a4rL2jZW1Eg+EMzSdtb+pL9e15QnGeKi43aSXNU//T+9KnoSNmavyIY/gRZhM/AGcCUJxII4LUNQSBVQTJXAiSwBSCzDEEKbWJIAxmQlCcSCOCkYTgLZAxzPM6/Dhg97zNqvTrY3wU+HMdAQ3xjPePTUxyn72k9Tss77M878HbBgT1hXm22dVj6xrNtOzw/pWWVfryNuIyuu0NhKil3wMfKcBHwXmcB4J9Q4o8eOuJcemrGEFgUY5AkuPKWzmGFuU4Jrj1Q4oCG1kEzUnRhRCzMfV9WK8uxCRAm3sDcoy58lYVBIPCiEFVcCHSG6iC1UhvxljdnCrIod5cENZAla/f6sHuyff2nvQlq771/v/eXjQe9H54Hyl4gGzygA7RA8FcJhEEUBsRoBysWiLCDZ5MBYAUXAit2oQADm0CC6dyYZi/RzjSRgU53tZLhQZyFRnAdCpg56gABCpEU6mABCoQfVSArliFeYlgN06AQyKAIJjKhFBgAtXHhFBiwp23MTMTYuag9RsGYmYnVpj6ugCtGkVt1VGNMbNikWnprSqIlZSAmlMF15Z6VK6iAduV6grzoLqicf3HXPgIVZmE1ajBz6zSdHnhPBcuyStVbLDrN71kAxqTTfjhNsWqKwLG3CZCrrlNKmtHA7UrlVgmyt3BSiySEywP3SZxjQpeGkpeKboCQymk2pRCc4bShZXagXaEsnYAq9ohZs00cj/9RmPSRj+UQ0i+KTZXh0IurN2+6zos12kF5SDuJ99oTMLlh3KIngOZUw5eVndGOXhAMFCOyCnPMTXENug5Qnlh887bRkJmr5EwHBOeut4roPI3doMxL1OVUF81wmSFDylqGHbZAJDo/yZ3jhhkgztFjLnZYNfd+mkbrqbhXNhFQvkXMeFsXahi9BUhtNpvrmlLqs6oU65X3CFP9UCMOonBjRehCxWLgSI4ta+QztY5wwmrQRWMLwfPvsIRKnpE7JapvAwNsOkeYx0ppIoLdo2CyAUQCLo8nQtYm1XAUOLCra8OUggUCTXXTodd6wtQqQe2mlMLQV8Xxl8aPOrzmFhfj6S5rgCu4A7ZyWHf/CV2UphJp5003lg5PxMUK+B2mSBu0KJ8D9mHmRAJNQKgjQhEDp5WvjpMsZOOQHCDjflMvlnaGZ/JWyT7CmL7BKLgJsIERRgjFESUW8puw0B0c/jGBCGGUcjYRO0Rjydi2lIPch01ai4wd5giOVU6l1MFUJ8tlZ3qMvTVlgr9RBiZyz6IvtLOREuqWMNx6zS+rqPl4tP49BlLrtM6jSU4V6cJ+qZy1piTWF3D8DL7oHLQac1tTneaipIE+ZOJfpgLcth866vTFCp2mNPagM+krlXsVIUap04gJlNDSmEerC85p+6kF9PrNFRBBLvBk592Um6AufPVTopL/xia68emY6rgfkqRmUvRqAsNFIMFIkWK5tZhzV1/y8WHNSN9RuY69tir0jRq9fANL10OM5Cwm6huKhI1u6bBTzYoVoq8DUCElaKQu1IDrpPJCa8JrZqoO+yP7syhO2Oycz80h+Gh5kTmQnfmTjo8u079KSJ/WKf0nX5okg3crfbZwOyeOe0jG8D1WFjx51GQuR4WMMbC+iFFcU8z35Rj4jBKmYu3vsqRiIeTGWxClsm49LY1TVBqgg22U4xJ472QotgRHxoU4rXuPyUAm2ySvJ7qu9ggRYlBOdIxO3n9kKO4DdSgUrMxbDylED/yYv2z/tZJvN8e5HQU3siEIvmc5fy6xchEwVYCIPwSAIuEGcbG/+i9iWZMBj+2HvWbIjl5k5KIpDTRjEh+bAnqN0USk87bXIqlYqoZf/1Vjj2XR8S6Rc0erMffdj+CGLzvtEz6KIQFQ8bkZLIrdvTBF0/5m+KkuNFUiFDWDG9ESBX5uD4RwrMilBNKb0SIFTmkPhGaOJurKbD227fHmuVhTZVbnX5NNXLJfE8/WCESJ9J3rkKkcbmFd+V3JfXLerG5jRwADu0CHt0EkB27dxCg3M5w60fwVPd9mBiQ04P3iHbpPLtBvYc+zz5p+WVCmDY3VezSAgg2XDwrajQNhIlC0aDMiLRca9jWMG5qZ7iVIK/dW/UWtC0P+n6zHZJc5sFZZus4v21feMiSJD9Xzhh67Rm87fkTbHpMCRVMEQ3yJG8rFyaKMknLbLe5XolDcs63mZC4XEA4ppbrbZztrlfm6Gw8YULmH0v113m832frsY5jrHuw5QoAr1l1op987DV6b6YZ19kDOR39jUBDUkvDVNCQ2GYxH2j107Ioqv7lB1/9pUjSwxX/Aw== -------------------------------------------------------------------------------- /assets/dag_lamport.xml: -------------------------------------------------------------------------------- 1 | 7V3BcqM4EP2aXFNIAgHHSWZ29rBTtVU57OyRjYnNjGNShEyS/frFNsKgllWOg5oWmxxSRrYBd78ndT+1xIW4vn/5WmUPq2/lIl9f8GDxciE+X3AeCtH83za87htkyvYNy6pY7Jt6DTfFv3nbGLStT8Uifxx8sC7LdV08DBtvy80mv60HbVlVlc/Dj92V6+FVH7JlDhpubrM1bP2rWNSrfWvC40P773mxXKkrM5nu3/knu/25rMqnTXu9Cy7udn/7t+8zda72hz6uskX53GsSXy7EdVWW9f7V/ct1vt6aVplt/73fjrzb3XeVb+pTvsD3X/iVrZ9ydce7+6pflS3yzeLT1qTN0abcNI1Xq/p+3Ryx5uVjXZU/8+tyXVa7Twu5+2vegXfS3txj+VTdtufm4b4tXwz80d7r17y8z+vqtfnA88ELUWu6Vc8Bqq3K11ld/Bp6MWvBsOxO113hz7Jo7o4HLW6T9jQtaiMZDM+wv/X2S32r2s/DUu08dVYt8xqcp3nR+9GHpp3PzP4T0/pPJKT8x/hIDtRP5NCD4bQebD5JyYM8GMmD+okcejCa1oNhSsqDTI7FQYnmQQk8+Am4sM5fapvfWr/eFeu11pSti+WmObxtvJg37Ve/8qoummDjU/vGfbFYbC9z9bwq6vzmIdu59rmJrJq2XTCRb280sCFie878xer/9l3dP2qw6sEjNMCDB8eRMDC9xc4xsPPVfO3M9K4M0dAJMPT1jA0dTmfoFBj684wNrcfHiIZmME4KgKWbrzQZ4jF79ByQPT7s08a74mVroYHxDzmbwQNjmDHVzBhBM3JXZpwgWNmP00M3EglWnIWbobNYhcGUz1siRBMSAcZ8uEQQpIjgLGp3SAQGPCg8JUKs2SxF5AEMFXF5wEjxwJEC6JAFwWyGg3i60YBDK8bzsKJA7Es47JGd9yV9JYwZ+hf1u2j2L6GuaZHrX5QLez5NZsKMGJEZE8/TqN8wYAanzAxBnxlQkVDZte/U4JhDLxSFcanBDdSgpVLo1IipU4NBWVTOgxkhQ2QGtKKBGl5YkbGhGSOOZ0YBY3vnHcygMyE2P+uqRsJddyJgXuHrQKsTIQxjPCLAUB53pE0hOZRrqZJDtztBcsAwNJ0JOQRiGComruIRhpFD0ApDAaZ1UBMkB5zlURjznx2YMdTESZpiwoAdtCoXdVB3nRdddoQwIGBzyTBEgMeOcOoqbAnZoXxLlR30A6sQZh3M1wlmnR3cULnljB0TV7grJgzYQTvt6DovwuyAqoqq7fKfHRKRHVOvHjDkHcq3RNnRdV502SGgdMt8VcABO0JEdkxQpTdgh2HeVNDWc7kHei6sOWO+ltsAdmDmHVNn5SZBl/aKUIBqeuyIYN7hbWClFXiHEm+2I+LTkkPlin1yRMTSDr3o+2zJCq3oW93hDMrRdHIIxJw8mlixigxZhzIHUXKE9FdEhIasw1vFSmMHTwUeOyZWrNRPH+TkxLIOeaTzIswOQ9bhKzn0FaRqEMQgx8SClVIZB+SglXSAVaXnxlV4q0ojSA5vRw6dHIgZeQRHYFRyKCIM4iri5FB9F2FyQJ3F24xcI0eIuAhGjfSThVUmcsS0yXHuRCAeOSQHXvVWy9XIgbl2Uk6dkceQHMq1RMkRnrsOBpEcUMv1tjhXJwfiJLmcepNEbiAHLS1Xx/TZ6ycRyWFIyOeSkQs13Y/AjnjiuEoxYcAO2kmHUMMtXXbEBio0xrxpD8uqXpXLcpOtvxxatS3fei7OX4r6e+/13+r1prmh7/0D9c6PvK5f2525s6e6bJoO1/yjLB9GAo8p7jg1KD8ZFScPNDDT83ZNt94lYS7qjmFSgNslGVK9k1E1UZd0bkU04oBtWE3jbVWbzg7E1TTxxLmesc+ltZpGBzWnL6HH7moVu1E66I/SwWV0ZGS37vc6mEwxJDbEJlO0+UF5btKvF+pJnckjIsFdXd4RJBzDwQ4hJyHBtDibGBKYiC95IJNURhGLeahqG7qNDPhlHCWy+8iZOEnTy8MV4lS7SJhc8t5VpDMMuduX8W0YYif3JR7sfRHaERSPgiAeWBEUYSHI3Vyks/HI1AsRm79kkR1DyTgYYlYMSSQMqaoelxgCyoNCUHBWRGMou+XEECTtCErHQRC3IijGQhCcAXHbCx1Tu94SC9GfKGaxFUMyGAdDwoqhBAtDnAqG3oUgWhNGLLEjiI2DoNCKoBQLQe4UF0fjmKlCXmWsVBCU2hHEx0FQZEOQDLAQ5G4K2oygYTR9HoYMOh+xDdd4YMeQGAdD0oohhoUhd6XTjsYxU04fEVOKmR1B4TgIiq0I4lgIIqQxnx5PM1NWTwxF3I6iaBwUJVYUCSwUIejTI0dDhh2u1DPGqSDIrk7LcdRpblWnJZY6naCr02P0Q8KgDVGrcbUr1HIchVpYFWqJpVAnCAr1uP2QCUGcGIJ0fXro23HkaWGVpyWWPJ06lKePdjW2DuokEKk0nvDid+2pB+dPumu7pjicdE+xheZRhiR1k4Qry33EAqeDhfcggdgG4D4iwaHweySQOB56nIQDUzU9sa2uu0eqdDV15xbn6U820qv8RgQCgn57YpdwMhS4KeulBQUfuwRsFXac3NWABWKLbHzEwrR66uHobWqYIYGQtCrtfMQCetXuGP1CaNDWP7Dwbixg65vvnqkz4uAjVngvDhwqlG8VmE5Gwv9odACrrp0hgakcx7PhwQQGWqWMHnYLLPBSbBSmVbG0xghdWuBxdB4adGmBc+1EY6KB+4gGk7pA7KlRXnYNCKWmo2vPJih8zEK8Gwp0NMe39AvRBxhcgMFL2VFtdEn48VBegsHLOk4TGIg9DclHMMDoMYBg8GNTFW2PhW7ja4RNVTjsX719IKGG4u4Yw4yGPX7YPMzYqUMYZpzRfuoaqUPEXXEFTKa83XBKNyPitvQSytj+Puhb37hLzeFibO8PO8e57A4Yutv/rDmsyrLuB0iNLVbfykW+/cR/7V1bc5s4FP41fs0gCV14jJ1296UzO9OHbR+pITZTYjKYNMn++sUGYZDkhGB0c+uXxDLI9vm+c9WRvECrh5e/yvhx+6VI0nwBg+Rlge4WEAIQRvWfw8hrM4Ij1AxsyixpLzoNfM3+S9vBoB19ypJ0P7iwKoq8yh6Hg+tit0vX1WAsLsvieXjZfZEP3/Ux3qTSwNd1nMuj/2ZJtW1GGaSn8b/TbLPl7wxI+4V/xOufm7J42rXvt4Do/vhoXn6I+VztF91v46R47g2hTwu0Kouiav57eFml+UG2XGzNfZ/PvNp97jLdVWNuwM0Nv+L8KeWf+Pi5qlcui3SX3B5EWj/bFbt6cLmtHvL6Gaj/3Vdl8TNdFXlRHq9GwfFRv9LMkyaSoE8frR3aF0/lur2Kwk4INbnS4iGtytf6mucTCrgV3bYHAB8r0zyusl/Dt4xbMmy66bp3+KfI6g8Dg5a4rL2jZW1Eg+EMzSdtb+pL9e15QnGeKi43aSXNU//T+9KnoSNmavyIY/gRZhM/AGcCUJxII4LUNQSBVQTJXAiSwBSCzDEEKbWJIAxmQlCcSCOCkYTgLZAxzPM6/Dhg97zNqvTrY3wU+HMdAQ3xjPePTUxyn72k9Tss77M878HbBgT1hXm22dVj6xrNtOzw/pWWVfryNuIyuu0NhKil3wMfKcBHwXmcB4J9Q4o8eOuJcemrGEFgUY5AkuPKWzmGFuU4Jrj1Q4oCG1kEzUnRhRCzMfV9WK8uxCRAm3sDcoy58lYVBIPCiEFVcCHSG6iC1UhvxljdnCrIod5cENZAla/f6sHuyff2nvQlq771/v/eXjQe9H54Hyl4gGzygA7RA8FcJhEEUBsRoBysWiLCDZ5MBYAUXAit2oQADm0CC6dyYZi/RzjSRgU53tZLhQZyFRnAdCpg56gABCpEU6mABCoQfVSArliFeYlgN06AQyKAIJjKhFBgAtXHhFBiwp23MTMTYuag9RsGYmYnVpj6ugCtGkVt1VGNMbNikWnprSqIlZSAmlMF15Z6VK6iAduV6grzoLqicf3HXPgIVZmE1ajBz6zSdHnhPBcuyStVbLDrN71kAxqTTfjhNsWqKwLG3CZCrrlNKmtHA7UrlVgmyt3BSiySEywP3SZxjQpeGkpeKboCQymk2pRCc4bShZXagXaEsnYAq9ohZs00cj/9RmPSRj+UQ0i+KTZXh0IurN2+6zos12kF5SDuJ99oTMLlh3KIngOZUw5eVndGOXhAMFCOyCnPMTXENug5Qnlh887bRkJmr5EwHBOeut4roPI3doMxL1OVUF81wmSFDylqGHbZAJDo/yZ3jhhkgztFjLnZYNfd+mkbrqbhXNhFQvkXMeFsXahi9BUhtNpvrmlLqs6oU65X3CFP9UCMOonBjRehCxWLgSI4ta+QztY5wwmrQRWMLwfPvsIRKnpE7JapvAwNsOkeYx0ppIoLdo2CyAUQCLo8nQtYm1XAUOLCra8OUggUCTXXTodd6wtQqQe2mlMLQV8Xxl8aPOrzmFhfj6S5rgCu4A7ZyWHf/CV2UphJp5003lg5PxMUK+B2mSBu0KJ8D9mHmRAJNQKgjQhEDp5WvjpMsZOOQHCDjflMvlnaGZ/JWyT7CmL7BKLgJsIERRgjFESUW8puw0B0c/jGBCGGUcjYRO0Rjydi2lIPch01ai4wd5giOVU6l1MFUJ8tlZ3qMvTVlgr9RBiZyz6IvtLOREuqWMNx6zS+rqPl4tP49BlLrtM6jSU4V6cJ+qZy1piTWF3D8DL7oHLQac1tTneaipIE+ZOJfpgLcth866vTFCp2mNPagM+krlXsVIUap04gJlNDSmEerC85p+6kF9PrNFRBBLvBk592Um6AufPVTopL/xia68emY6rgfkqRmUvRqAsNFIMFIkWK5tZhzV1/y8WHNSN9RuY69tir0jRq9fANL10OM5Cwm6huKhI1u6bBTzYoVoq8DUCElaKQu1IDrpPJCa8JrZqoO+yP7syhO2Oycz80h+Gh5kTmQnfmTjo8u079KSJ/WKf0nX5okg3crfbZwOyeOe0jG8D1WFjx51GQuR4WMMbC+iFFcU8z35Rj4jBKmYu3vsqRiIeTGWxClsm49LY1TVBqgg22U4xJ472QotgRHxoU4rXuPyUAm2ySvJ7qu9ggRYlBOdIxO3n9kKO4DdSgUrMxbDylED/yYv2z/tZJvN8e5HQU3siEIvmc5fy6xchEwVYCIPwSAIuEGcbG/+i9iWZMBj+2HvWbIjl5k5KIpDTRjEh+bAnqN0USk87bXIqlYqoZf/1Vjj2XR8S6Rc0erMffdj+CGLzvtEz6KIQFQ8bkZLIrdvTBF0/5m+KkuNFUiFDWDG9ESBX5uD4RwrMilBNKb0SIFTmkPhGaOJurKbD227fHmuVhTZVbnX5NNXLJfE8/WCESJ9J3rkKkcbmFd+V3JfXLerG5jRwADu0CHt0EkB27dxCg3M5w60fwVPd9mBiQ04P3iHbpPLtBvYc+zz5p+WVCmDY3VezSAgg2XDwrajQNhIlC0aDMiLRca9jWMG5qZ7iVIK/dW/UWtC0P+n6zHZJc5sFZZus4v21feMiSJD9Xzhh67Rm87fkTbHpMCRVMEQ3yJG8rFyaKMknLbLe5XolDcs63mZC4XEA4ppbrbZztrlfm6Gw8YULmH0v113m832frsY5jrHuw5QoAr1l1op987DV6b6YZ19kDOR39jUBDUkvDVNCQ2GYxH2j107Ioqv7lB1/9pUjSwxX/Aw== -------------------------------------------------------------------------------- /assets/dag_rounds.xml: -------------------------------------------------------------------------------- 1 | 7V1Nc6M4EP01uabQBwKOk8zs7GGnaqtymNkjsYnNjmNShEyS/fWLbYRBkhVMUNMwySW2jAF3v9fqfvrggl3fv3zN44f1t2yZbC6ot3y5YJ8vKCUsiMp/u5bXQ0tAyKFhlafL6qBjw036X1I1elXrU7pMHlsHFlm2KdKHduMi226TRdFqi/M8e24fdpdt2ld9iFeJ1nCziDd66/d0WawPrSENju1/JulqLa9MRPWDb+PFz1WePW2r611Qdrf/O3x8H8tzVT/0cR0vs+dGE/tywa7zLCsOr+5frpPNzrbSbIfv/XHi0/q+82RbdPkCPXzhV7x5SuQd7++reJW2SLbLTzuTlu+22bZsvFoX95vyHSlfPhZ59jO5zjZZvj+aif1f+Yl+J9XNPWZP+aI6N+WHtmTZ8kd1r1+T7D4p8tfygOejF/zKdOuGA2RbnmziIv3V9mJcgWFVn66+wt9ZWt4d9SrghtVpKtT6wmuf4XDr1ZeaVrWfh0TKeYo4XyWFdp7yReNHH5v2PjP7j43rPxai8h+hAzlQPZFDD/JxPVgeicmD1BvIg+qJHHrQH9eDPELlQSKG4qAA86DQPPhJc2GRvBQ2v1V+vUs3G6Up3qSrbfl2UXoxKduvfiV5kZbJxqfqg/t0udxd5up5nRbJzUO8d+1zmVqVbftkItndqGdDxO6cyYvV/9Wnqn9kZ9WABzfAg3qnkdAyvcXOgWbnq/namaihDNDQoWbo6xkbmo9n6Egz9OcZG1rNjwENTfQ8ydMsXX6lrBBP2aPhgPjx4VA23qUvOwu1jH+o2ehiYfKA1lkvxa3wrZ31GQaOFAP7uoGpKwOPkMYcevC2g5GkMc4SUe4siyF6MThDivgjUkTPE2EpwlBRxFmm75AiRPMgmx1FAsWaESBD9MQTliEEFUMc6YkO+eH9Bl1IMF4PQnX7Bg7tGy6Sjva9DX3uD1QmKPZlgPGH6vHdefxpanHEEJPk78IZk7iqqqGLSdKFDZ+Gs+dMAMiZkceQ5G9ocYZi5gzDzxldLZH1vQvSJGTpJ0En0kQiYLGbjpxCduS6lA1LGmogDS4FRSVNgJ00RBdzxdw7Gk4AOaPb10CaiRcXhLQN7FM4AzO9unAelFoBCNlItKvZIO5CENPrF4fdNhKKcB7AUUQvJmD77UinjXQ6VtqodkdIGz3djWbXc6u0YYDpLht5jhMz9DYMV7qroV2FO0La6ONZEmMzqhI13kBmZCOXiZIjLd7gmvGpwr0Oa3h5w/UkgjisZLDwxoPjDR97XrvQeSO9jpU3+NM0rlc3xOHwOxLeUMMsOWe8GXk1geRIize4y5s6rCHmja7ryNlyc+aNAOTN2Gs4DPWN9DpS3tRhDS9vmC44E4eKPhbecEDejDAjssUbw9gxw61C0wmo0PosPuJwmtIyTsK7bnqaWITJ7Z0j3kDWN2PrAiYZGvdaXg3v+Hjj6/WNwzQNyQR8LuBGb3w6Lm1ktdqkjY+svFEn5feW08Am5cs7nPUEP5U2DFAV8EdW03xDdSPNgZQ2HP9aFm6obmaopim8oRGD483Iapr86S1VAFl1I06ENcS8MVQ3DrsbJCuJZZcKQZuRxTSpjbZog6u40VYX983S4FYX+zpt5rd0UqMNoCbg6/05KG0kRVpZGnLayKiGmDa60jNDTUChDQdcviTzhtGSNBNtAty06TvkCUcbQTWvzm+hrEobyJWyYmxNINBpI52OlDa87womQNroCvQMJ0KrtAGcKCDG3q6TGmiDS4FW0d57tSwgbQySgENNYCwpTeWNnAwBwJtg5CxNcqTFG9zFDZNdNF7eBAaSlMa8qd5mebHOVtk23nw5tirbEjZcnLykxY/G63/k6215Qz+ab+Qn/yZF8VrtHh8/FVnZdLzmX1n2MBB4TLlK1xS/Myo6d0F6RTnDtf1qsIJc3B/oxQdssDKUlJ3xNlKw6jv7HLCTN6x2muFsQJU3gKudgpFrSmOcxrXaSYU7xS/8B+7meNY9u9fs2b1L/0Q2YC0gW0NAhjIJ2RCQMt4p+ooL6jRGoTJ5QCS4m7V4AgmncLBHSCckmBbcI0MCYcEl9UQYCd8nAeVyFke9bQW9DPxQ1If0xEkUXR6vEETKRXh4SRtXEc4w5G6H0PMwRDrHkgnsdMLtCAoGQRD1rAjyoRDkbpzUWX9kikLIxlaJb8dQOAyGiBVDAghDcpaSSwxpaoVEkNcrozFMPabIECTsCIqGQRC1IiiAQpA+0uI2Cp1SyM7JhfAPVZPAiiHhDYMhZsVQCIUhigVD70IQruEnEtoRRIZBELciKIJCkDvFxVE/ZloLICtWLAiK7AiiwyDItyFIeFAIcjegbUZQO5vuhyGDzodsEz3q2THEhsGQsGKIQGHI3YRvR/2Yqab3kSnFxI4gPgyCAiuCKBSCEGnM3fNpYqrqkaGI2lHkD4Oi0IoiBoUiAH164GzIsM8Yw/WUL2pXp8Uw6jS1qtMCSp0OwdXpIeIQM2hD2ObS2hVqMYxCzawKtYBSqEMAhXrYOGRCEEWGIFWfbvt2GHmaWeVpASVPRw7l6ZOhxhagOoFIlvGIl/krT7/oP+iu7CnjcNA9ghaaB+mS5E0inqc+RSxQPFh4DxKQbd0+RSQ4FH5PJBKnU49OODDNwEe2FXn9AJ16Tl3fyXnqs6/UWX4DAgFAv+0YEjpDgZqqXlxQmGJIgFZhh6ldDVhAtjBnilgYV089vjtPDTMUEALXTLspYgF81u4QcYEbtPUPLLwbC9D65rtH6ow4+MgV3osDhwrluQJTZyT8Rr2DtlLbGRKIrHEm1j2YwIBrKuMEwwLxJik2MtN6WVx9hCot0MDvhwZVWqBUOdGQaKBTRINJXUD27K5JhgaAqaaDa88mKHyMQrwbCng0x3Pigv8BBhdgmKTsKDfhRPzArUmCYZLzOE1gQPYUqSmCQc8ePR0MU9/5Vtl9od7IG2C7FapH3hk+FlJBfv0ewsCGHYPI3A1ca00QBv4t9pRXQgQH3OWX6UWbwy2vxtoPVjUw4Kb9QhfS5/goeHVTMTm+DPFYBD0IO9ztEMmWxhxw17aaPucl7cv4cb3fxZN0zeAPn3yvfhHdGT/bFtX2neRoSSXlNph2rCycK12lfIzn+avH3zjRgFm4zFg+vPumd9tLCjjnfb37xol6e7d8m2dZ0Ty8jHDrb9ky2R3xPw==7V1bc5s4FP41fs0gCV14jJ1296UzO9OHbR+pITZTYjKYNMn++sUGYZDkhGB0c+uXxDLI9vm+c9WRvECrh5e/yvhx+6VI0nwBg+Rlge4WEAIQRvWfw8hrM4Ij1AxsyixpLzoNfM3+S9vBoB19ypJ0P7iwKoq8yh6Hg+tit0vX1WAsLsvieXjZfZEP3/Ux3qTSwNd1nMuj/2ZJtW1GGaSn8b/TbLPl7wxI+4V/xOufm7J42rXvt4Do/vhoXn6I+VztF91v46R47g2hTwu0Kouiav57eFml+UG2XGzNfZ/PvNp97jLdVWNuwM0Nv+L8KeWf+Pi5qlcui3SX3B5EWj/bFbt6cLmtHvL6Gaj/3Vdl8TNdFXlRHq9GwfFRv9LMkyaSoE8frR3aF0/lur2Kwk4INbnS4iGtytf6mucTCrgV3bYHAB8r0zyusl/Dt4xbMmy66bp3+KfI6g8Dg5a4rL2jZW1Eg+EMzSdtb+pL9e15QnGeKi43aSXNU//T+9KnoSNmavyIY/gRZhM/AGcCUJxII4LUNQSBVQTJXAiSwBSCzDEEKbWJIAxmQlCcSCOCkYTgLZAxzPM6/Dhg97zNqvTrY3wU+HMdAQ3xjPePTUxyn72k9Tss77M878HbBgT1hXm22dVj6xrNtOzw/pWWVfryNuIyuu0NhKil3wMfKcBHwXmcB4J9Q4o8eOuJcemrGEFgUY5AkuPKWzmGFuU4Jrj1Q4oCG1kEzUnRhRCzMfV9WK8uxCRAm3sDcoy58lYVBIPCiEFVcCHSG6iC1UhvxljdnCrIod5cENZAla/f6sHuyff2nvQlq771/v/eXjQe9H54Hyl4gGzygA7RA8FcJhEEUBsRoBysWiLCDZ5MBYAUXAit2oQADm0CC6dyYZi/RzjSRgU53tZLhQZyFRnAdCpg56gABCpEU6mABCoQfVSArliFeYlgN06AQyKAIJjKhFBgAtXHhFBiwp23MTMTYuag9RsGYmYnVpj6ugCtGkVt1VGNMbNikWnprSqIlZSAmlMF15Z6VK6iAduV6grzoLqicf3HXPgIVZmE1ajBz6zSdHnhPBcuyStVbLDrN71kAxqTTfjhNsWqKwLG3CZCrrlNKmtHA7UrlVgmyt3BSiySEywP3SZxjQpeGkpeKboCQymk2pRCc4bShZXagXaEsnYAq9ohZs00cj/9RmPSRj+UQ0i+KTZXh0IurN2+6zos12kF5SDuJ99oTMLlh3KIngOZUw5eVndGOXhAMFCOyCnPMTXENug5Qnlh887bRkJmr5EwHBOeut4roPI3doMxL1OVUF81wmSFDylqGHbZAJDo/yZ3jhhkgztFjLnZYNfd+mkbrqbhXNhFQvkXMeFsXahi9BUhtNpvrmlLqs6oU65X3CFP9UCMOonBjRehCxWLgSI4ta+QztY5wwmrQRWMLwfPvsIRKnpE7JapvAwNsOkeYx0ppIoLdo2CyAUQCLo8nQtYm1XAUOLCra8OUggUCTXXTodd6wtQqQe2mlMLQV8Xxl8aPOrzmFhfj6S5rgCu4A7ZyWHf/CV2UphJp5003lg5PxMUK+B2mSBu0KJ8D9mHmRAJNQKgjQhEDp5WvjpMsZOOQHCDjflMvlnaGZ/JWyT7CmL7BKLgJsIERRgjFESUW8puw0B0c/jGBCGGUcjYRO0Rjydi2lIPch01ai4wd5giOVU6l1MFUJ8tlZ3qMvTVlgr9RBiZyz6IvtLOREuqWMNx6zS+rqPl4tP49BlLrtM6jSU4V6cJ+qZy1piTWF3D8DL7oHLQac1tTneaipIE+ZOJfpgLcth866vTFCp2mNPagM+krlXsVIUap04gJlNDSmEerC85p+6kF9PrNFRBBLvBk592Um6AufPVTopL/xia68emY6rgfkqRmUvRqAsNFIMFIkWK5tZhzV1/y8WHNSN9RuY69tir0jRq9fANL10OM5Cwm6huKhI1u6bBTzYoVoq8DUCElaKQu1IDrpPJCa8JrZqoO+yP7syhO2Oycz80h+Gh5kTmQnfmTjo8u079KSJ/WKf0nX5okg3crfbZwOyeOe0jG8D1WFjx51GQuR4WMMbC+iFFcU8z35Rj4jBKmYu3vsqRiIeTGWxClsm49LY1TVBqgg22U4xJ472QotgRHxoU4rXuPyUAm2ySvJ7qu9ggRYlBOdIxO3n9kKO4DdSgUrMxbDylED/yYv2z/tZJvN8e5HQU3siEIvmc5fy6xchEwVYCIPwSAIuEGcbG/+i9iWZMBj+2HvWbIjl5k5KIpDTRjEh+bAnqN0USk87bXIqlYqoZf/1Vjj2XR8S6Rc0erMffdj+CGLzvtEz6KIQFQ8bkZLIrdvTBF0/5m+KkuNFUiFDWDG9ESBX5uD4RwrMilBNKb0SIFTmkPhGaOJurKbD227fHmuVhTZVbnX5NNXLJfE8/WCESJ9J3rkKkcbmFd+V3JfXLerG5jRwADu0CHt0EkB27dxCg3M5w60fwVPd9mBiQ04P3iHbpPLtBvYc+zz5p+WVCmDY3VezSAgg2XDwrajQNhIlC0aDMiLRca9jWMG5qZ7iVIK/dW/UWtC0P+n6zHZJc5sFZZus4v21feMiSJD9Xzhh67Rm87fkTbHpMCRVMEQ3yJG8rFyaKMknLbLe5XolDcs63mZC4XEA4ppbrbZztrlfm6Gw8YULmH0v113m832frsY5jrHuw5QoAr1l1op987DV6b6YZ19kDOR39jUBDUkvDVNCQ2GYxH2j107Ioqv7lB1/9pUjSwxX/Aw== -------------------------------------------------------------------------------- /assets/dag_bx.xml: -------------------------------------------------------------------------------- 1 | 7V1bc6s4Ev41edwUuiDg8SRze5ip2qps1cw+EpvYzCEmg8lJsr9+sY2wUcuYEEk0JHmJLWPA3d/X6v504YrdPr7+WsRP6z/yZZJdUW/5esV+uqKUsCCq/u1a3g4tASGHhlWRLuuDjg136f+SutGrW5/TZbJtHVjmeVamT+3GRb7ZJIuy1RYXRf7SPuwhz9pXfYpXCWi4W8QZbP0zXZbrQ2tIg2P7b0m6WssrE1H/4Pt48X1V5M+b+npXlD3s/w4fP8byXPUP3a7jZf5y0sR+vmK3RZ6Xh1ePr7dJtrOtNNvhe7+c+bS57yLZlH2+QA9f+BFnz4m84/19lW/SFslm+W1n0urdJt9UjTfr8jGr3pHq5bYs8u/JbZ7lxf5oJvZ/1SfwTuqb2+bPxaI+N+WHtmTZ8kd9r78m+WNSFm/VAS9HL/i16dYnDpBtRZLFZfqj7cW4BsOqOV1zhX/naXV31KuBG9anqVHrC699hsOt1186tWr3eUiknKeMi1VSgvNUL05+9LFp7zO9/9i4/mMhKv8RasiB6oksepCP68HqSEwepJ4hD6onsuhBf1wP8giVB4kwxUHhzIMCePAbcGGZvJZdfqv9+pBmmdIUZ+lqU71dVF5MqvabH0lRplWy8a3+4DFdLneXuXlZp2Vy9xTvXftSpVZV2z6ZSHY36nUhYnfO5LXT//Wnqn9kZ3UCD66BB/XOI6Fl+g47B8DON/O1M1FDmUNDh8DQtzM2NB/P0BEw9E8zNrSaHzs0NIF5kgcsXX2lqhDP2ePEAfH26VA2PqSvOwu1jH+o2ehiofMA6KyX4l74nZ31OwwcKQb2oYGpLQOPkMYcevC2g5GkMdYSUW4tiyGwGJwhRfwRKQLzRLcUYagoYi3Tt0gRAjzIZkeRQLFm5JAhMPF0yxCCiiGW9ESL/PA+QRcSjNeDUGjfwKJ9w0XS0773oc99Q2WCYl/mMP5QGN+tx59TLY5oYpL8XThjEldVNXQxSbrwxKfh7DkTOOTMyGNI8je0OEMxc4bh5wxUS2R9b4M0CVn6SdCLNJEIWGynI6cuO3IoZbslDdWQBpeCopImwE4aAsVcMfeOhhOHnIH21ZBm4sUFIW0D+9SdgRmsLqwHpVYAQjYSbWs2iL0QxGD9YrHbRkIRzgN3FIHFhNt+O4K0kU7HShvV7ghpA9PdaHY9t0ob5jDdZSPPcWKa3obhSncB2lW4I6QNHM+SGJtRlQh44zIjG7lMlBxp8QbXjE8V7k1Yw8sbDpMIYrGSwcIbzx1v+Njz2gXkjfQ6Vt7gT9M4rG6IxeF3JLyhmlly1ngz8moCyZEWb3CXN01YQ8wbqOvI2XJz5o1wyJux13Bo6hvpdaS8acIaXt4wKDgTi4o+Ft5wh7wZYUZkizeasWOGW4WmE1Ch4Sw+YnGa0jJOwod+eppYhMn9gyXeuKxvxtYFdDI07rW8AO/4eOPD+sZimoZkAj4X7kZvfDoubWS1ekobH1l5o07KHyynOZuUL+9w1hP8VNowh6qAP7Ka5muqG2kOpLTh+NeycE11M0M1TeENjZg73oyspsmf3lIFkFU34kxYQ8wbTXVjsbtBspJYdqkuaDOymCa10RZtcBU3YHXx0CzN3epiH9JmfksnAW0cagI+7M+d0kZSpJWlIaeNjGqIaQOVnhlqAgptuMPlSzJvGC1J09EmwE2boUOe7mgjKPDq/BbKqrRxuVJWjK0JBJA20ulIacOHrmBySBuoQM9wIrRKG4cTBcTY23VSDW1wKdAq2gevlnVIG40kYFETGEtKU3kjJ0M44E0wcpYmOdLiDe7ihskuGi9vAg1JKmPe1W/zolznq3wTZz8fW5VtCU9cnLym5V8nr/8rX2+qG/rr9I385O+kLN/q3ePj5zKvmo7X/D3PnwyBR5er9E3xe6OidxcEK8oZru1Xg5XLxf0BLD7cBitNSdkbbyMFq6Gzzx128prVTjOcDajyxuFqp2DkmlIbp3GtdlLhTvEL/4G9OZ5Nz+6d9uzetX8mG+gsIFtDQJoyCdkQkDLeKYaKC+o0RqEy2SAS7M1aPIOEczjYI6QXEnQL7pEhgbDgmnoijITvk4ByOYuj2baCXgd+KJpDBuIkiq6PVwgi5SI8vKYnVxHWMGRvh9D3YYj0jiUT2OmEdyMoMIIg6nUiyHeFIHvjpNb6I10UQja2SvxuDIVmMEQ6MSQcYUjOUrKJIaBWSAR5gzIazdRjigxBohtBkRkE0U4EBa4QBEda7EahcwrZe3Ih/EPVJOjEkPDMYIh1Yih0hSGKBUMfQhCu4ScSdiOImEEQ70RQ5ApB9hQXS/2Ybi2ArFixICjqRhA1gyC/C0HCc4UgewPaegS1s+lhGNLofMg20aNeN4aYGQyJTgwRVxiyN+HbUj+mq+l9ZEox6UYQN4OgoBNB1BWCEGnM/fNpoqvqkaGIdqPIN4OisBNFzBWKHOjThrMhzT5jDNdTvmi3Oi3MqNO0U50WrtTp0Lk6bSIOMY02hG0ubbdCLcwo1KxToRauFOrQgUJtNg7pEESRIUjVp9u+NSNPs055WriSpyOL8vTZUNMVoHqBSJbxiJf5K0+/GD7oruwpY3HQPXItNBvpkuRNIp6nPkUsUDxY+AgSkG3dPkUkWBR+zyQS51OPXjjQzcBHthV58wCdZk7d0Ml56rOv1Fl+BoHgQL/tGRJ6Q4Hqql5cUJhiSHCtwpqpXTVYQLYwZ4pYGFdPPb57nxqmKSAErpl2U8SC81m7JuIC12jrX1j4MBZc65sfHqnT4uArV/goDiwqlO8VmHoj4RP1DmCltjUkEFnjTKx70IEB11TGCYYF4k1SbGS69bK4+ghVWqCBPwwNqrRAqXIik2igU0SDTl1A9uyuSYYGB1NNjWvPOih8jUJ8GAp4NMf3xAX/Cww2wDBJ2VFuwon4gVuTBMMk53HqwIDsKVJTBAPMHj0IhqnvfKvsvtBs5O1guxUKI+8MHwupIL9578LAmh2DyNwN3GhNLgz8KfaUV0IEd7jLL4NFm8Utr8baD1Y1sMNN+wUU0uf4KHh1UzE5vuzisQgwCFvc7RDJlsbc4a5tDX3el7Qv4+16v4sn6ZvBHz75s/5FdGf8fFPW23eSoyWVlFtj2rGycK50lfIxnu9fPX7hRAazcJmxfHn3onfbSwo450O9e+FEJr3bQ5Vtb7h7IUAq8fCX/Z/GmSA+ngl5vfx7ZmyDa4opoguDxEwc7CFrTtaWrK8t1Qe4DTNlD1FwsqZsEpCLsFSH7YfZ0p6m1o7ZRGPPo+p2nMIBVpydme13OdKri/I1OlwNJSQ9/mDdTcnvbMpuxN58P2x40axarEH0hZf+eIEizE2WL75fNVsMzyFo984lmJGYDWUBadPqtkVWXevmvqherXavTszt/VYl3vCI+fihdx5ixA/yxBo/0PN+IJ/AD72TGDN+gEXof4p4s40XZZpvtvMxK9c81l1rVvX54sPMSj+JWVlfs5pBKyyq22Y9hIVl+qNlXvHPc75rr352+a/aKt+qI7LkoTx+egwlh7NUd7M/UbvVzrlHgUNLSrIRyfyekcz3TWADVrZ31Q+Oy+cimRHhfO6UcLDEnaNRuWZo1aJRYR04R6PqxqvtGZXBhBKYcruOn3YvF89F9nZTxIvvu+L0kk2PDvhYtE2LZN9N7S6SbEtDRmdBG8lywOLC+JQZYZbB7PEzGp35rJfRQxP9HIOp5We0OZXqyCWgy1H/jxnd3hz7HtKdaXnuYKepK3FMORFVNwUZLMVVb4t8l7cfD6/Isv4jXya7I/4P7V1bc5s4FP41fs0gCV14jJ1296UzO9OHbR+pITZTYjKYNMn++sUGYZDkhGB0c+uXxDLI9vm+c9WRvECrh5e/yvhx+6VI0nwBg+Rlge4WEAIQRvWfw8hrM4Ij1AxsyixpLzoNfM3+S9vBoB19ypJ0P7iwKoq8yh6Hg+tit0vX1WAsLsvieXjZfZEP3/Ux3qTSwNd1nMuj/2ZJtW1GGaSn8b/TbLPl7wxI+4V/xOufm7J42rXvt4Do/vhoXn6I+VztF91v46R47g2hTwu0Kouiav57eFml+UG2XGzNfZ/PvNp97jLdVWNuwM0Nv+L8KeWf+Pi5qlcui3SX3B5EWj/bFbt6cLmtHvL6Gaj/3Vdl8TNdFXlRHq9GwfFRv9LMkyaSoE8frR3aF0/lur2Kwk4INbnS4iGtytf6mucTCrgV3bYHAB8r0zyusl/Dt4xbMmy66bp3+KfI6g8Dg5a4rL2jZW1Eg+EMzSdtb+pL9e15QnGeKi43aSXNU//T+9KnoSNmavyIY/gRZhM/AGcCUJxII4LUNQSBVQTJXAiSwBSCzDEEKbWJIAxmQlCcSCOCkYTgLZAxzPM6/Dhg97zNqvTrY3wU+HMdAQ3xjPePTUxyn72k9Tss77M878HbBgT1hXm22dVj6xrNtOzw/pWWVfryNuIyuu0NhKil3wMfKcBHwXmcB4J9Q4o8eOuJcemrGEFgUY5AkuPKWzmGFuU4Jrj1Q4oCG1kEzUnRhRCzMfV9WK8uxCRAm3sDcoy58lYVBIPCiEFVcCHSG6iC1UhvxljdnCrIod5cENZAla/f6sHuyff2nvQlq771/v/eXjQe9H54Hyl4gGzygA7RA8FcJhEEUBsRoBysWiLCDZ5MBYAUXAit2oQADm0CC6dyYZi/RzjSRgU53tZLhQZyFRnAdCpg56gABCpEU6mABCoQfVSArliFeYlgN06AQyKAIJjKhFBgAtXHhFBiwp23MTMTYuag9RsGYmYnVpj6ugCtGkVt1VGNMbNikWnprSqIlZSAmlMF15Z6VK6iAduV6grzoLqicf3HXPgIVZmE1ajBz6zSdHnhPBcuyStVbLDrN71kAxqTTfjhNsWqKwLG3CZCrrlNKmtHA7UrlVgmyt3BSiySEywP3SZxjQpeGkpeKboCQymk2pRCc4bShZXagXaEsnYAq9ohZs00cj/9RmPSRj+UQ0i+KTZXh0IurN2+6zos12kF5SDuJ99oTMLlh3KIngOZUw5eVndGOXhAMFCOyCnPMTXENug5Qnlh887bRkJmr5EwHBOeut4roPI3doMxL1OVUF81wmSFDylqGHbZAJDo/yZ3jhhkgztFjLnZYNfd+mkbrqbhXNhFQvkXMeFsXahi9BUhtNpvrmlLqs6oU65X3CFP9UCMOonBjRehCxWLgSI4ta+QztY5wwmrQRWMLwfPvsIRKnpE7JapvAwNsOkeYx0ppIoLdo2CyAUQCLo8nQtYm1XAUOLCra8OUggUCTXXTodd6wtQqQe2mlMLQV8Xxl8aPOrzmFhfj6S5rgCu4A7ZyWHf/CV2UphJp5003lg5PxMUK+B2mSBu0KJ8D9mHmRAJNQKgjQhEDp5WvjpMsZOOQHCDjflMvlnaGZ/JWyT7CmL7BKLgJsIERRgjFESUW8puw0B0c/jGBCGGUcjYRO0Rjydi2lIPch01ai4wd5giOVU6l1MFUJ8tlZ3qMvTVlgr9RBiZyz6IvtLOREuqWMNx6zS+rqPl4tP49BlLrtM6jSU4V6cJ+qZy1piTWF3D8DL7oHLQac1tTneaipIE+ZOJfpgLcth866vTFCp2mNPagM+krlXsVIUap04gJlNDSmEerC85p+6kF9PrNFRBBLvBk592Um6AufPVTopL/xia68emY6rgfkqRmUvRqAsNFIMFIkWK5tZhzV1/y8WHNSN9RuY69tir0jRq9fANL10OM5Cwm6huKhI1u6bBTzYoVoq8DUCElaKQu1IDrpPJCa8JrZqoO+yP7syhO2Oycz80h+Gh5kTmQnfmTjo8u079KSJ/WKf0nX5okg3crfbZwOyeOe0jG8D1WFjx51GQuR4WMMbC+iFFcU8z35Rj4jBKmYu3vsqRiIeTGWxClsm49LY1TVBqgg22U4xJ472QotgRHxoU4rXuPyUAm2ySvJ7qu9ggRYlBOdIxO3n9kKO4DdSgUrMxbDylED/yYv2z/tZJvN8e5HQU3siEIvmc5fy6xchEwVYCIPwSAIuEGcbG/+i9iWZMBj+2HvWbIjl5k5KIpDTRjEh+bAnqN0USk87bXIqlYqoZf/1Vjj2XR8S6Rc0erMffdj+CGLzvtEz6KIQFQ8bkZLIrdvTBF0/5m+KkuNFUiFDWDG9ESBX5uD4RwrMilBNKb0SIFTmkPhGaOJurKbD227fHmuVhTZVbnX5NNXLJfE8/WCESJ9J3rkKkcbmFd+V3JfXLerG5jRwADu0CHt0EkB27dxCg3M5w60fwVPd9mBiQ04P3iHbpPLtBvYc+zz5p+WVCmDY3VezSAgg2XDwrajQNhIlC0aDMiLRca9jWMG5qZ7iVIK/dW/UWtC0P+n6zHZJc5sFZZus4v21feMiSJD9Xzhh67Rm87fkTbHpMCRVMEQ3yJG8rFyaKMknLbLe5XolDcs63mZC4XEA4ppbrbZztrlfm6Gw8YULmH0v113m832frsY5jrHuw5QoAr1l1op987DV6b6YZ19kDOR39jUBDUkvDVNCQ2GYxH2j107Ioqv7lB1/9pUjSwxX/Aw== -------------------------------------------------------------------------------- /attacks.md: -------------------------------------------------------------------------------- 1 | **How will Fantom prevent attacks?** 2 | 3 | **Introduction** 4 | 5 | In a decentralized environment one of the key design considerations is 6 | the presence of adversarial attackers. This is further compounded by the 7 | financial nature of blockchains. 8 | 9 | We will define common attacks and how they are circumvented as well as 10 | speculate on potential new attack vectors that might arise due to our 11 | design 12 | 13 | **Attack Vectors** 14 | 15 | **Transaction Flooding** 16 | 17 | A malicious participant may run a large number of valid transactions 18 | from their account under their control with the purpose of overloading 19 | the network. In order to prevent such a case, the chain intends to 20 | impose a minimal transaction fee. Since there is a transaction fee, the 21 | malicious user cannot continue to perform such attacks. Participants who 22 | participate in nodes are rewarded, and those who contribute to the 23 | ecosystem, such as by running transactions, are continuously rewarded. 24 | Such rewards are expected to be adequate in running transactions for 25 | appropriate purposes. However, since it would require tremendous cost to 26 | perform abnormal attacks, it would be difficult for a malicious attacker 27 | to create transaction flooding. 28 | 29 | **Parasite Chain** 30 | 31 | In a DAG-based protocol, a parasite chain can be made with a malicious 32 | purpose, attempting connection by making it look like a legitimate event 33 | block. When the Main Chain is created, verification for each event block 34 | is performed. In the verification process, any block that is not 35 | connected to the Main Chain is deemed to be invalid and is ignored, as 36 | in the case of double spending. 37 | 38 | We suppose that less than one-third of nodes are malicious. The 39 | malicious nodes create a parasite chain. By the witness definition, 40 | witnesses are nominated by 2n/3 node awareness. A parasite chain is only 41 | shared with malicious nodes that are less than one-third of 42 | participating nodes. A parasite chain is unable to generate witnesses 43 | and have a shared consensus time. 44 | 45 | **Double Spending** 46 | 47 | A double spend attack is when a malicious entity attempts to spend their 48 | funds twice. Entity A has 10 tokens, they send 10 tokens to B via node A 49 | and 10 tokens to C via node Z. Both node A and node Z agree that the 50 | transaction is valid, since A has the funds to send to B (according to 51 | A) and C (according to Z). 52 | 53 | Consensus is a mechanism whereby multiple distributed parties can reach 54 | agreement on the order and state of a sequence of events. Let’s consider 55 | the following 3 transactions 56 | 57 | *txA*: A (starting balance of 10) transfers 10 to B 58 | 59 | *txB*: B (starting balance of 0) transfers 10 to C 60 | 61 | *txC*: C (starting balance of 0) transfers 10 to D 62 | 63 | In a centralized environment the above doesn’t present any problems, we 64 | simply process the results asynchronously. In a distributed environment 65 | however we cannot be assured of the ordering. 66 | 67 | We consider Node A that received the order *txA txB txC* 68 | 69 | The state of Node A is A:0, B:0, C:0, D:10 70 | 71 | Now, we consider Node B that receives the order *txC txB txA* 72 | 73 | The state of Node B is A:0, B:10, C:0, D:0 74 | 75 | Consensus ordering gives us a sequence of events. 76 | 77 | *If the pair of event blocks (x, y) has a double spending transaction, 78 | the chain can structurally detect the double spend and delay action for 79 | the event blocks until the event blocks assign time ordering.* 80 | 81 | Suppose that the pair of event blocks (x, y) has same generation g. 82 | Then, all nodes must detect two event blocks before generation g+2. By 83 | the witness definition, each witness supra-shares more than 2n/3 84 | previous witnesses. For this reason, when two witnesses in g + 1 are 85 | selected, they must supra-share same the witnesses which are more than 86 | one-thirds of witnesses in g. This means that more than n/3 witnesses in 87 | g + 1 share both two witnesses which include the pair respectively. With 88 | the witness definition and previous explanation, all witness in g + 2 89 | share both the pairs. Thus, all nodes detect the double spending event 90 | blocks at g+2 or earlier. 91 | 92 | **Long-range attack** 93 | 94 | In blockchains an adversary can create another chain. If this chain is 95 | longer than the original, the network will accept the longer chain. This 96 | mechanism exists to identify which chain has had more work (or stake) 97 | involved in its creation. 98 | 99 | 2n/3 participating nodes are required to create a new chain. To 100 | accomplish a long-range attack you would first need to create > 2n/3 101 | participating malicious nodes to create the new chain. 102 | 103 | **Bribery attack** 104 | 105 | An adversary could bribe nodes to validate conflicting transactions. 106 | Since 2n/3 participating nodes are required, this would require the 107 | adversary to bribe > 1n/3 of all validators to begin a bribery 108 | attack. 109 | 110 | **Denial of Service** 111 | 112 | We are a leaderless system requiring 2n/3 participation. An adversary 113 | would have to deny > 1n/3 participants to be able to successfully 114 | mount a DDoS attack. 115 | 116 | **Sybil** 117 | 118 | Each participating node must stake a minimum amount of FTM to 119 | participate in the network. Being able to stake 2n/3 total stake would 120 | be prohibitively expensive 121 | 122 | **Quantum Attacks** 123 | 124 | Cryptographic protocols are susceptible to attack by the development of 125 | a sufficiently large quantum computer. Of specific interest to 126 | cryptocurrencies is how this relates to proof-of-work and more 127 | specifically, the elliptic curve signature scheme. Optimistic estimates 128 | state that this can be broken by a quantum computer as early as 2027, it 129 | is therefore important to adopt a post-quantum signature scheme. 130 | 131 | Signatures are often based on the Elliptic Curve Digital Signature 132 | Algorithm secp256k1 curve. The security of this system is based on the 133 | hardness of the Elliptic Curve Discrete Log Problem (ECDLP). 134 | 135 | How quickly can a quantum computer compute the Elliptic Curve Discrete 136 | Log Problem? An instance with a *n* bit prime field, can be solved using 137 | 9n + 2 \[log2(n)\]+10 logical qubits and (448log2(n)+4090)n3 Toffoli 138 | gates. Bitcoin uses n=256 bit signatures. 139 | 140 | For 10GHz clock speed and error rate of 10−5 , the signature is cracked 141 | in 30 minutes using 485550 qubits. 142 | 143 | So if all Elliptic Curve Digital Signature Algorithms are susceptible, 144 | then how can you implement a quantum proof solution? 145 | 146 | 147 | 148 | In blockchain context we care about signature and public key lengths 149 | (since these have to be stored to fully verify). 150 | 151 | Hash based schemes like XMSS have provable security. Grover’s algorithm 152 | can still be used to attack. DILITHIUM at 138 bits require time 2125 153 | 154 | A truly quantum proof cryptographic algorithm does not currently exist. 155 | Instead, the our architecture allows for multiple cryptographic 156 | implementations to be plug and play, given the modular architecture 157 | design. Since we aren’t focusing on tightly coupled architecture, it 158 | means we could implement ECC, XMSS, and DILITHIUM (and something new we 159 | haven’t announced yet). 160 | -------------------------------------------------------------------------------- /assets/dag_frames_bx.xml: -------------------------------------------------------------------------------- 1 | 7V1Lc6NIEv41jj61g3rxOLZ7umcOMxEb642Y2SMtsMQ0Fh6Mu+399YskCkFlCSNEJQW2Dw6pJBXSl19m5auKK/b5/vnXPHzY/JFFcXpFnej5iv1yRanvO+X/3cDLYYBz/zCwzpPoMESOA7fJ/+JqsPrc+imJ4sfWG4ssS4vkoT24yrbbeFW0xsI8z36233aXpe2rPoTrGAzcrsIUjv6ZRMWm+lnUO47/FifrjbwycYPDK9/C1fd1nj1tq+tdUXa3/zu8fB/Kuaof+rgJo+xnY4h9uWKf8ywrDo/unz/H6Q5aCdvhc19PvFp/7zzeFn0+QA8f+BGmT7H8xvvvVbxILOJt9GkHaflsm23LwZtNcZ+Wz0j58LHIs+/x5yzN8v27mbv/K1+B36T6co/ZU76q5qb8MBZHLXlU3/XXOLuPi/ylfMPPoxREBd2mIQA5lsdpWCQ/2lIMKzKs6+nqK/wrS8pvRx3J22qairXCddozHL569aEmqt3zkECZpwjzdVyAecoHjR99HNrLTC8/Nq38mG+V/AgdSYDqRAYlyKeVYPlOmyRInZEkqE5kUIJiWgnywCoJEncsHXTRJOgCCX4CIizi56JLbpVc75I0VYbCNFlvy6erUopxOX7zI86LpHQ2PlUv3CdRtLvMzc9NUsS3D+FetD9Lz6oc2zsT8e6LOl2M2M0ZP3fKv3pVlY9crBr04Bp6UOc0E1rQd+DsAZxvloszUU0ZItA+APrzgoHm0wEdAKB/WTDQqn+MCDSBfpLz4cMHuNKmaRkknoKkIYPw8eEQOd4lzzuQWvgfwja6WumEANbryP3mis71+gyMAwVjATGmpjCewJM5LOJtGVviyRjzRbkxR4bAeNBZopKICZUEOou4SsKsUhJj7r5BJSFAgmxxKuIpaAaIGgK9T1wNIVZpiKGkokH9cOAisnT9wFxBKMTXM4ivv4p74vvNF1yMFCso+DJE+0OhfTduf5oJOaKxSfJ32WmTuJpas84mSRE2ZOovXmdYgKczExeS5G9o6Qy1WWeY/ToDUyYywjehNDGJROz1UprA9VhoZiGvvU8MpYH5bFyloRqlsSuHoiqNZ7vSEJjRdZe+0HCC6JxBfDVKM/PggpA2wILiAcxgdGHcKLUMkGXlaFMtIeZMEIPxi8FleyITpKoI5x6eisBgAnfdDqDaSKHbqjYq7haqDXR3g8WrDSN4MSKbuNGJaVYbZpe7C9iu0t1CtYH1LMmxBUWJqt5QHy9MZBOHiVJHWnpjV9unSncmrNcbDp0IYjCSsUVvXDy94VM3t7tQb6TUbdUb+900DqMbYrD8bovecES9mXhLgdSRlt7YHd4wx369gXkdwg22dtmiOBRRcabeyaEJcKTYLVWcOjFvr+LIKmpTcQym9G3RGwdRbyZoiWzpjaZ4LKVuq97MIA0N2/iIwT6lKIz9u34JNXflx9/uzOgNwQxwpk4M6PLQdu/oBXy3T28EDHC4ObWZKg+tdOBzF698I+i0aiPD1abaCMviG7Urf3A+Da0rX37DZoffAsMbRW+Y3L2NoTcT59OEJryRcFiqN9z+3SxcE96w5SsOdQme4kycUJM/vZUXsCy+UfjOBucF8BRHE9+YUxtbthMjptPExOk0uZ24pTZ2hTdgi/FQPw1vi7GAasOWuMVYVRwJMIbiwCUdVXGkkrQcNcsVR9o1ixUHZntM1m8s0RvMxIB0HSbz03R649mtN0MLn3h641IgVc+k3kyUUAtUB5rj6c3UiQEP6o2UuqV6w4duZELUG5iHDt6A3lC8hJo79dmdVKM3diWiVboP3jWLqDeavABZYEJNURyKuOB4EztqUklaimN3gMPkIm2v4nia9FkJ5m31NMuLTbbOtmH65TiqHFLYEHH8nBR/NR7/Vz7ell/or+YT+crfcVG8VGfJh09FVg4dr/l7lj2MRB6dt9LXy+/Nit5rEIwqiXgD1gpxm78HAxBca6UJK3sTbiJrNbQPHXGZ1+x7cpevOARx45M3cVyptdR2bXxS+U7tLwB45ro967Xdaa7tzrU44Q90xpCtUpAmUrKsFKTUPd2hCQa1odFVNXlEJpjrXzzBhFM82DOkFxN0e+8tYwJh3jV1XD9whSAe5bLfrD7Bgl57wnfrtwzkSRBcH6/gBcpFuH9NG1dxjXHI3GGh53GI9LYlMzj0hHczyBuFQdTpZJDAYpC5aqmx9UhnhSyrsBLRzSF/HA6RTg65SByS3UomOQTyFZJBziCPRtOETC1jkNvNoGAcBtFOBnlYDILVFrNW6FSO7BxfyP56NfE6OeQ643CIdXLIx+IQtYVDFzHIrgoU8bsZRMZhEO9kUIDFIHMZF0PrmG5TgIxYbWFQ0M0gOg6DRBeDXAeLQeZq2noGtb3pYRzS5PksO0+POt0cYuNwyO3kEMHikLnGb0PrmC6mF5Zlikk3g/g4DPI6GUSxGGRRjrm/P010Ub1lLKLdLBLjsMjvZBHDYhFCfnpkb0hz5Biz64ZftDs77Y6Tnaad2WkXKzvto2enx7BDTJMbsq2ftjtD7Y6ToWadGWoXK0PtI2Sox7VDOgZRyxik5qfbsh0nPc0609MuVno6MJiePmlqugxULxLJMN7i/f7KjTCGF92V02UMFt0D7ETzKEuS/JIWt6rPkQvUHi5cwgTLTnGfIxMMJn5POBKnXY9ePND14Ft2Knl9L526p25oc556Gyy1y29EIiDkb3uahN5UoLqo1y4qzNEkYGdhx4ldNVywbGvOHLkwbT71+Oy8bJgmgHDt6rSbIxfQu3bHsAtck1t/58LFXMDOb15cqdPy4N1XuJQHBjOU5yaYejPhDa0O6iEHxBgTiIxxZrY86MhgVyvjDM0CcWaZbGS6DbN2rRFqaoF6Yhgb1NQCpcpEY7KBzpENuuyCZbfxmqVpQGg1HT33rKPCexXiYirYk3M8xy6IdzKYIMMs047yFh0W33prlmSYZR+njgyW3U9qjmSA3qOzwPNvleMX6hO9Ec5bodD0yjPQF3SijUL9OtrDAFhzZhBZPMAeIsC6w+UXbyN4gGcjGAzbTJ56NdWpsArCTLZFYJwKq7khD13+wWL1abgYN0iAdtjkmYeWHG3M5f4iBIRrBTrPc4/Cx83+ME/S140/vPJn9YvoDvxsW1SneJJOJC1xxbliaojSBt5/C/krE43oikuv5V26r0q3va+Acz5Uuq9MNKZ0e6Rm2+fuvmIgFXv4df+nESawjyNYQS6PX5XAaQIqojODZBw72CO3OVss62NaX8VSLTgPw9JcNqhtaIgGz2O+6Nh8APZK9e9Ts8Q8CaZI1BHX1Bce4Yf/0t0/11yBealzLefc/zdnvMy1p6GTpH3EgGZPXW1eLKETVcQ+OK9Yn2WEkFckMGlwk2ar71f7M3HdtITo5ltePlrvHn3Nw/v4t9KTgS+Natjr3MKrhv10rmGdh1FSvq01bRR0n4CMsLSyUVYDGCdLsZEzxXYY2QFdfnhVg+X+85Qd3iBhawwdPtsgitOcvfz2h+nalzDFFRlgns+VOuDUcCUOSyIZ4kpv10Hd6jKIKxTGK//Jw+1juCqSbPv45hXX7ykM9XbWw4RBEYUxQ83wegpDPaJ9mDBgzee2RCYsnvL4zeuF4JgLmqY6ZEoU89MKTjBFISfpCiIeN+HD7uHqKU9fbvJw9X3nlb8miaPYLgrmoySP9+Zyd5H4sRgH9NL2tEHn/W6+Ok6qhMFF+i2CrvOM9DkVfwzQe+RUZpOfUpuZtQEJ02DpizGg7JF5mC2Ugol+ULJRoIQhuQOwnHsZv1b0mq0QYmP1OQaj5y8/yt9SzvkJIF3+oKIrSVYl0ZqwVkMS0TS+282wAydZhemnavg+iaL0lATbutK78HOJuYAC4KYEwOFqt8B2NiZ3SkzBcXntFsQLxFh2TkyCMawVlhgvEGR5pOwkIMMiosG2QVuWQ01SyhzCMA0CnbfZI6waY1SEYaDBloewaopREYbxxwKbX4EhRoVY11+8QIwVUywcvN5MwmFkwhcIsWKLUSEW0DH+d5a96dhPSEcWI/YT0Gn+KEvEUfKjJQBZcd7J4WMFaSklp6IpqEg3KtD7qV4tN5PXdQhogrP/mzhFBayURoTaxOkYeVOh2RgVrePb6mmWF5tsnW3D9MtxVGF1A+DTvUGnOop2r7X6aWFPUznyNdn9gv2b/46L4qUSSfhUZOXQ8Uv+nmUPp2R9RvvTSaG2GpmErpFJ9L1LQe8Opf6iFO+iHLGv+sIWMsa8a7dxMLuUznE/5PX+JHXiMM59quhy74PZL7rKiM1nAnqU70vB5d4U6lIAHdaPiwRZCW5RQZadR4sHWQlvcUHuUYGfbQVT23ForBgs75ezSCi5g1kMdmG0tMDdmqp1ZRSxwODCAsObrwbrBGAsI+DC+oO7PIoraxsuxWH9YYEHF6g5EYZ4fAxxYQHCWx7CSqjBZL4aBWEYLXoLJLG6FKJCDKM5f3kIq5aYB9eIttiDcUawPIxVU+xhIgzDj2CBhkK1xagQQ4firRfR6tuwYrjM3lnt1kMSQnW999ydTJWwDBgRHcLG0kGeZuF7L4ycEmqrxiXJ2apxeX1vKDB+jcvTrK/vojwlyolrXJyOVuPyGodu+OpF2tOOWNSSy8KyTbPaTYlpmv2zMvVzRVjtpkRFGHrQC0RYbaZERbjHMWML3O/J5T7Xjk2K5jbZ+j3OI3sDoDM5BcomWx9m93eHxaxLDDcA/ctjxRpLu6LFoO2A1Ec6NUTgmQoWfRis708EgucqLBZ+Rtoq4GqOgzWHPwzW90cnrTZhsn07MuCBN6EMYPHA4On+w1OCAE4N6P2zrpg1Rh/WDjS9pXNHWE26mkO4fJpnu5bGYyC6WzL/yKJ4947/Aw==7V1bc5s4FP41fs0gCV14jJ1296UzO9OHbR+pITZTYjKYNMn++sUGYZDkhGB0c+uXxDLI9vm+c9WRvECrh5e/yvhx+6VI0nwBg+Rlge4WEAIQRvWfw8hrM4Ij1AxsyixpLzoNfM3+S9vBoB19ypJ0P7iwKoq8yh6Hg+tit0vX1WAsLsvieXjZfZEP3/Ux3qTSwNd1nMuj/2ZJtW1GGaSn8b/TbLPl7wxI+4V/xOufm7J42rXvt4Do/vhoXn6I+VztF91v46R47g2hTwu0Kouiav57eFml+UG2XGzNfZ/PvNp97jLdVWNuwM0Nv+L8KeWf+Pi5qlcui3SX3B5EWj/bFbt6cLmtHvL6Gaj/3Vdl8TNdFXlRHq9GwfFRv9LMkyaSoE8frR3aF0/lur2Kwk4INbnS4iGtytf6mucTCrgV3bYHAB8r0zyusl/Dt4xbMmy66bp3+KfI6g8Dg5a4rL2jZW1Eg+EMzSdtb+pL9e15QnGeKi43aSXNU//T+9KnoSNmavyIY/gRZhM/AGcCUJxII4LUNQSBVQTJXAiSwBSCzDEEKbWJIAxmQlCcSCOCkYTgLZAxzPM6/Dhg97zNqvTrY3wU+HMdAQ3xjPePTUxyn72k9Tss77M878HbBgT1hXm22dVj6xrNtOzw/pWWVfryNuIyuu0NhKil3wMfKcBHwXmcB4J9Q4o8eOuJcemrGEFgUY5AkuPKWzmGFuU4Jrj1Q4oCG1kEzUnRhRCzMfV9WK8uxCRAm3sDcoy58lYVBIPCiEFVcCHSG6iC1UhvxljdnCrIod5cENZAla/f6sHuyff2nvQlq771/v/eXjQe9H54Hyl4gGzygA7RA8FcJhEEUBsRoBysWiLCDZ5MBYAUXAit2oQADm0CC6dyYZi/RzjSRgU53tZLhQZyFRnAdCpg56gABCpEU6mABCoQfVSArliFeYlgN06AQyKAIJjKhFBgAtXHhFBiwp23MTMTYuag9RsGYmYnVpj6ugCtGkVt1VGNMbNikWnprSqIlZSAmlMF15Z6VK6iAduV6grzoLqicf3HXPgIVZmE1ajBz6zSdHnhPBcuyStVbLDrN71kAxqTTfjhNsWqKwLG3CZCrrlNKmtHA7UrlVgmyt3BSiySEywP3SZxjQpeGkpeKboCQymk2pRCc4bShZXagXaEsnYAq9ohZs00cj/9RmPSRj+UQ0i+KTZXh0IurN2+6zos12kF5SDuJ99oTMLlh3KIngOZUw5eVndGOXhAMFCOyCnPMTXENug5Qnlh887bRkJmr5EwHBOeut4roPI3doMxL1OVUF81wmSFDylqGHbZAJDo/yZ3jhhkgztFjLnZYNfd+mkbrqbhXNhFQvkXMeFsXahi9BUhtNpvrmlLqs6oU65X3CFP9UCMOonBjRehCxWLgSI4ta+QztY5wwmrQRWMLwfPvsIRKnpE7JapvAwNsOkeYx0ppIoLdo2CyAUQCLo8nQtYm1XAUOLCra8OUggUCTXXTodd6wtQqQe2mlMLQV8Xxl8aPOrzmFhfj6S5rgCu4A7ZyWHf/CV2UphJp5003lg5PxMUK+B2mSBu0KJ8D9mHmRAJNQKgjQhEDp5WvjpMsZOOQHCDjflMvlnaGZ/JWyT7CmL7BKLgJsIERRgjFESUW8puw0B0c/jGBCGGUcjYRO0Rjydi2lIPch01ai4wd5giOVU6l1MFUJ8tlZ3qMvTVlgr9RBiZyz6IvtLOREuqWMNx6zS+rqPl4tP49BlLrtM6jSU4V6cJ+qZy1piTWF3D8DL7oHLQac1tTneaipIE+ZOJfpgLcth866vTFCp2mNPagM+krlXsVIUap04gJlNDSmEerC85p+6kF9PrNFRBBLvBk592Um6AufPVTopL/xia68emY6rgfkqRmUvRqAsNFIMFIkWK5tZhzV1/y8WHNSN9RuY69tir0jRq9fANL10OM5Cwm6huKhI1u6bBTzYoVoq8DUCElaKQu1IDrpPJCa8JrZqoO+yP7syhO2Oycz80h+Gh5kTmQnfmTjo8u079KSJ/WKf0nX5okg3crfbZwOyeOe0jG8D1WFjx51GQuR4WMMbC+iFFcU8z35Rj4jBKmYu3vsqRiIeTGWxClsm49LY1TVBqgg22U4xJ472QotgRHxoU4rXuPyUAm2ySvJ7qu9ggRYlBOdIxO3n9kKO4DdSgUrMxbDylED/yYv2z/tZJvN8e5HQU3siEIvmc5fy6xchEwVYCIPwSAIuEGcbG/+i9iWZMBj+2HvWbIjl5k5KIpDTRjEh+bAnqN0USk87bXIqlYqoZf/1Vjj2XR8S6Rc0erMffdj+CGLzvtEz6KIQFQ8bkZLIrdvTBF0/5m+KkuNFUiFDWDG9ESBX5uD4RwrMilBNKb0SIFTmkPhGaOJurKbD227fHmuVhTZVbnX5NNXLJfE8/WCESJ9J3rkKkcbmFd+V3JfXLerG5jRwADu0CHt0EkB27dxCg3M5w60fwVPd9mBiQ04P3iHbpPLtBvYc+zz5p+WVCmDY3VezSAgg2XDwrajQNhIlC0aDMiLRca9jWMG5qZ7iVIK/dW/UWtC0P+n6zHZJc5sFZZus4v21feMiSJD9Xzhh67Rm87fkTbHpMCRVMEQ3yJG8rFyaKMknLbLe5XolDcs63mZC4XEA4ppbrbZztrlfm6Gw8YULmH0v113m832frsY5jrHuw5QoAr1l1op987DV6b6YZ19kDOR39jUBDUkvDVNCQ2GYxH2j107Ioqv7lB1/9pUjSwxX/Aw== -------------------------------------------------------------------------------- /assets/roots_1.xml: -------------------------------------------------------------------------------- 1 | 7V3Lctu4Ev0aV3Yu4kGAXCZOMncxU3WrspiZJSNRlmZk0SXTiXO//upBUCQAURQNNJq0vUhkSqak7nMa6ING44bdPbz8ts0el38U83x9Q6P5yw37fEMpiVm6+29/5dfxikzY8cL9djWvXnS68G31v7y6GFVXn1fz/Kn1wrIo1uXqsX1xVmw2+axsXcu22+Jn+2WLYt1+18fsPjcufJtla/Pqn6t5uTxeTag8Xf9PvrpfqncmovrC37PZv/fb4nlTvd8NZYvDz/Hph0zdq/qiT8tsXvxsXGJfbtjdtijK46OHl7t8vbetMtvx776eebb+3Nt8U/b6A0KPf/IjWz/n6jMfPln5S1kj38w/7o26+21TbHYXPy3Lh/XuN7J7+FRui3/zu2JdbA+vZuLws3vG/CzVx3sqnrezvDbd8WI+b7mk+ri/5cVDXm5/7V7w8+SIuLLesuEDdW2br7Ny9aPtyKzCw319u/od/lusdh+PRhV2mfqTCrkxl+1bHD989VdNy164EZHajcpse5+Xxo12Dxpf+3Tp4LhzTmSBnUiROVG4cqIAdCIP7ETGUDmRc0dO1G/k1YlxaCYmuJwYuXJiBOhEYThR+bXpxvV6Nx3Zu+/nclXm3x6zgxN+7mZEbZdmT4/HOcpi9ZLv3uPTYrVeNzyck3mcy/0L16v7ze7abOfhfGsDQyokyzrB8CPflvlLp+dVbCNti1JSQaeBDGpBhrpmA0HL6p0mlqaJo+mZONZMnEaAJk5ME1uC0dRMLCBRnMJH+2Oc03yMJNrr0yWaJMOivX4j7TYOY73CQZMlbPos4YAsqT9usBQzsVBHfTWs1BH4qUNN6vAP0+cOheRO8Mw+snGH4uYOx88dM9lXWceUqRNBUid4Kk5t1OG4qaNjHiF1LNm59EedeZYni1kv6ohZkn9f+KEOgcxrqJmdA1OH26iDW2Sugxti6lgkATbBGVuqz6UJIHdMTYCQ6dmYMz3VF3A2ZhapcBcUvlW/FttyWdwXm2z95XT102FVdm/Bz1HbwvnLqvyr8fhv9Xiz+1x/NX9Rz/yTl+WvatU6ey6L3aXTe/5eFI+OwqCycSsMqosXw2Dv+Nbf7mYmT+I3gG1IZZyZWbX3sXcYvsIsA9KEDxtm9Rv5G2aZmbQTMX2akASSJsFXy63cwb2EXgcyxNzxl7XX43nUHM+j27hjDtAPCxzZMoy2sivY0Mwkjm7TmLIkqv4VbTilHnFgZvmhcHB85iwSsDhdXuer3tRnF+7Lb0kacSmqf2N/kPCnSjiGhLUipzVQ8BQXeJxFDL3yTl8BdokHU83wi4dzyWL0OiwgmzSMEwv+KjHO8/9M1HjdAsFUI4ORVEt/aOBmUccoRgobHpCl46OMDip7GRseBP7Rgkt97Z0Nw0Os75dItRu5xAMdJR64bfaArQRwlPHBX5XN1Xh4HRqwVbWNEg3+pEWv0UG+48EPHvBIktfggdhmD+qjv+PhFXgYjTTZAw/IytFGiQfLXiZuImLkq33GdjEGuNrHTalPfZwpm1hCmthSt0Snv2hNBYezcdxDlzqVKZHLRjZM9ZWkd2lqWvvr4Wd/vdiUVeUSiWzWz7az6vm9GZ3AWhVGViZnKmA2TS59mbxHqj9Bk3N5Gwc0eo8ManpG5zSs0f2lKcdnVCccYjGvmpyepqpKzDhNaU9rJtdVV8T2HFZfN0nszoGZuIqo5Xg+eOOrpoIyVQ7oYd4a+8tjegCmAxbnwdQPMFZlTFERSaZTtwJQiFEx82rEcO1GkXYjl4jxV4ERFjFqltBW1pEjZnCM0RGjJ9kuEeOvRuN1iOmFCypTCy6Qt9hhZGizKx0X1N8KXOyvXiNwJLHuXMNV0zHKSCLM3PmjAZndTL3swkmFo2bSUF0y8oP9vH81y9YfqyceVvP5+pzu0d5bdBYp1+TMtE1qaWYS3JdMobTThqk/TdjUPKSpTXnibsKmTkKa2lzk/zxdU3Ma0tTOpYjvSczjqNforilCi2SWz2bNUd/YzjlgzO+TKFhnBsFmidpQzWLN0X3HfG3uIHTAuBzyQwoUF2HUsUQ7cPJoTzeQFQTzqHM/yPDsQ8rbJJaE0+O/afu2jNme9QG6kBrHWZggcT6j2oSfD4wiejjiPsNISA3i7XpUePRoSPVgdB5NRuBR6W/HxrtHz3o0jjx61N+ei+l5NNaHP5QeNbWKd4/696g+ILv0qL99D+P36EVH9F/T127kcxz13RalW+NQe7YMr4ZyYnLB9H19qN2HpB5d6LtvaacL6zMC0LiQXKJPXx/qN/LqRH/SVR8nqi46aJxII1dOTNPbtPGjZG0In/ruinqBmAkynxLhyqcCkJimGIR7GdlY8umFAHtZYqyGMYhFIGmKNLhXkV9laaIHOEhTq/cazSry60ytT8xBTW3KGp8nbGp9/gxqalNviD588LglabFY0Fm/Vu9z8V3EwpGRtSXVODaN7G1LUuL7gJHuqn3lYzyTmu755eA5jj4B9qjqJKYGEE2RNnFI2oAn6W3acGy08ZUL+OSJmaN7PPktEEukZk7IEygT8IS5TRKBjCSexEifFDGz5WjqFIEdR8wk2eNZRnUR22UD1wWX7g3MIGOQeq9ACyKJremKcjrWwMR1/Q1fYErNNDyZPG9Uk1sQ3pjJNyhvbJWwaX8LBuENGwFvLEeToDza3iVxQM/vSQOvwNtmwtiX5ZnETxwz4fd4XiuOAYcTyImamY1biDPyVIOQtoXrKjEQC4dNx1Ns6bi3whKfYchMyD0O34HCkM4Sbmuj5I0l/vYW9Bq/bQljiq70w1W1Kxx16gWYhmPTyVOHEbickUZmUg5KHUvbp9rraKkzeMMVJHVMMUDhbEJZo84dCnieJY3A1+FbxYWKJm3uUOTcGbyJHZI7ph5ALK6dGncEJHfCVswrmrS5g26FXufOGKZspiZAPC7RY+EOh+RO2KJ2RZM2d7ArBUzfZYmRO5aW+RxlP3e35KGQ5AmqFdQ8aZMHu1ZAh+5eBySPAlWTPB7lfizciQC5Q4KKBfVXbXFH2QMvd/BL1HV20+SOx5qmeZYni35Cm5gl+feFH+4QyISHhBUL1Fdvc4di584IhDZiigXcH3VCadRa4T4XcMs7dbVLqLomW75D0GkFejX/YJ0NrJq/np81KwInmO5o3GGqOyQIdwJvgLdyB51WoEMe/06Yuj6upbNNnzxUNToHIU9YrcB2+if+lhJssFYARx6FjiZ5/FEHyx5lSJmNBpUK6j3KLeqoL4aGOkaHnaFzNridynWFZ3MH5hR3KuvkURYGIU9YrUB9hzZ5sGkFBnnowBNxIMlj0Qqmzx1QsYCGLSxQ79bmDjaxwODO0MVRSO6YYoH0yZ1AQpvGHabUJxDuhBULqE0soNjEAgPyQzdCQXLHFAvSN8AdCii00bBaAbVpBRSbVqBDfvDuW0DuMItWQCYotGnkoZADDwtbWEBthQXK73jJI7SzXjGSx+LHnSu+Vb8W23JZ3BebbP3ldFVridjwsjqrSz3+Wz0+e0zcP3lZ/qo62GfPZbG7dHrP34vi0Ql+GLPhp/8G7t7A6E8oW8+ANxC0ALsGUBa0a0Adn4aCLlDQGlrCDhm0TAmBiOmTh0DunWKBm+1bIzb2Dvx0BOsDzJ+G0OcYz+bUIOoJBmGb/qFbLNJWR8VQ2UGvgvR4Gixl/o5xPAOGc1A4gKQHGKyb+fGBgTB5SyORpCKOiaRcVZfWbTHorYwTUb9kIFT2jZXrd5Cp9iY8uaWNdxH+YORPW7kORqTv8rO1IwQ2JZPwbhBJJyCiUSeIYigQqTFvPAPTmVhEscEo7oZR4gZGpBNGAgxG/qSqHqfdDwCRtXxZ9s8WoKrIukGUugER7QSRBAMRBY5F59Sz3vOiGjG4F7aJ7ISRiNzAiHXCKAGDkb86oSth9BoQ4dtKkXSDiLgBEe8EUQoGIn8yppcBzbqnAF9/bpJ2g4i6AVHcBSIRgYHIX9WVHUTtyfUQGNmqTfB17aNRN4yYGxiJThgRMBj5U4W9DGjWRJ9KbAPablrUCSLuBkSyE0QUDESIFOj+smM8CiDRbiDFboCUdAKJgQEJQL12OjOSliGNSooNRN3atXCjXdNO7VqAadccXLt+fTSqMYO8ErdbvxZu9GvWqV8LMP06BtCv3UYjC4jwnQdDdfW67V434jXrFK8FmHitPr8PDJ0NOF1hqgeOrOcK4eshoJ3DMXx5Xutc43N5PqbjG5usp+Xgq3QfJRyg5WQHK6Q2MKDrHz9KMHiUhc9MKs5PQ3pAwV7Ej64del22W1fiDS3p08/j0msDXWIBQN3tGRj6okFRDDcaRhkYoDVaFwmttd87uh0+o4RDWLX19NtVS4hW2R7b3olRwgG84tdBdCC2qcM7HFzAAVr9fG2FihUK6DaGjBEKav8CBu2p76zhbcUFvX0C8QgGgCpa95NIa2yYLBwgYwMdIRxU93TcQ4UuOFAZD8ODLjjUnbZ84AGREtl/0dQqOWAr4RhleAAoUXW8p9QOhvdFKwdgwCNG9o8NwraG+Q4HF3AYoRxJVAEA7lPARgmHURZ/2uCA7mCrUcLBlCOjCTbc1Vo61H3EITq5CFPiUzt0JtQsRwN/3dkCwsLqvVsdCCdvYQlpYVOO8nmWCpIwwVPAMKGqQRsm9tlTK1QLWs3ELOWAJrY0/aPT71tWywMgNjalCJ99FZF0UubqJCQQEw9K8OfZ0/LQM5T0nc8fn/mz+kZ0b/xiU1bNQkmH0INmRs61YEO0yvGr+hk0fqTsvq/DCboclL6/SWe3dyZwtW//+r4DF27k0rtmbjDBAx5Z2rYoU+f3QETLxN9KapszxMKZkyRyWm03tg71rdAyDK5pqNYzvY4ICxeAo/2+HsFiyZKEEdUGQQFBzciu5ejhvvH+KL3qX6EFZH6bxJJwWv3rjcDK5l3oOrXrJpcpbKDtK0nv0tTk8tfDjwVzBrez7ax6fu8nJ4RO5K3mSW7JRqUvSjtf/aznhpcpfW4C6rQY8wLV60M/MVE91oL8Yd9g42fgsjrbNx2z3KemevfbDOb67tdtUZTNl+/IuvyjmOf7V/wf7V1bc5s4FP41fs0gCV14jJ1296UzO9OHbR+pITZTYjKYNMn++sUGYZDkhGB0c+uXxDLI9vm+c9WRvECrh5e/yvhx+6VI0nwBg+Rlge4WEAIQRvWfw8hrM4Ij1AxsyixpLzoNfM3+S9vBoB19ypJ0P7iwKoq8yh6Hg+tit0vX1WAsLsvieXjZfZEP3/Ux3qTSwNd1nMuj/2ZJtW1GGaSn8b/TbLPl7wxI+4V/xOufm7J42rXvt4Do/vhoXn6I+VztF91v46R47g2hTwu0Kouiav57eFml+UG2XGzNfZ/PvNp97jLdVWNuwM0Nv+L8KeWf+Pi5qlcui3SX3B5EWj/bFbt6cLmtHvL6Gaj/3Vdl8TNdFXlRHq9GwfFRv9LMkyaSoE8frR3aF0/lur2Kwk4INbnS4iGtytf6mucTCrgV3bYHAB8r0zyusl/Dt4xbMmy66bp3+KfI6g8Dg5a4rL2jZW1Eg+EMzSdtb+pL9e15QnGeKi43aSXNU//T+9KnoSNmavyIY/gRZhM/AGcCUJxII4LUNQSBVQTJXAiSwBSCzDEEKbWJIAxmQlCcSCOCkYTgLZAxzPM6/Dhg97zNqvTrY3wU+HMdAQ3xjPePTUxyn72k9Tss77M878HbBgT1hXm22dVj6xrNtOzw/pWWVfryNuIyuu0NhKil3wMfKcBHwXmcB4J9Q4o8eOuJcemrGEFgUY5AkuPKWzmGFuU4Jrj1Q4oCG1kEzUnRhRCzMfV9WK8uxCRAm3sDcoy58lYVBIPCiEFVcCHSG6iC1UhvxljdnCrIod5cENZAla/f6sHuyff2nvQlq771/v/eXjQe9H54Hyl4gGzygA7RA8FcJhEEUBsRoBysWiLCDZ5MBYAUXAit2oQADm0CC6dyYZi/RzjSRgU53tZLhQZyFRnAdCpg56gABCpEU6mABCoQfVSArliFeYlgN06AQyKAIJjKhFBgAtXHhFBiwp23MTMTYuag9RsGYmYnVpj6ugCtGkVt1VGNMbNikWnprSqIlZSAmlMF15Z6VK6iAduV6grzoLqicf3HXPgIVZmE1ajBz6zSdHnhPBcuyStVbLDrN71kAxqTTfjhNsWqKwLG3CZCrrlNKmtHA7UrlVgmyt3BSiySEywP3SZxjQpeGkpeKboCQymk2pRCc4bShZXagXaEsnYAq9ohZs00cj/9RmPSRj+UQ0i+KTZXh0IurN2+6zos12kF5SDuJ99oTMLlh3KIngOZUw5eVndGOXhAMFCOyCnPMTXENug5Qnlh887bRkJmr5EwHBOeut4roPI3doMxL1OVUF81wmSFDylqGHbZAJDo/yZ3jhhkgztFjLnZYNfd+mkbrqbhXNhFQvkXMeFsXahi9BUhtNpvrmlLqs6oU65X3CFP9UCMOonBjRehCxWLgSI4ta+QztY5wwmrQRWMLwfPvsIRKnpE7JapvAwNsOkeYx0ppIoLdo2CyAUQCLo8nQtYm1XAUOLCra8OUggUCTXXTodd6wtQqQe2mlMLQV8Xxl8aPOrzmFhfj6S5rgCu4A7ZyWHf/CV2UphJp5003lg5PxMUK+B2mSBu0KJ8D9mHmRAJNQKgjQhEDp5WvjpMsZOOQHCDjflMvlnaGZ/JWyT7CmL7BKLgJsIERRgjFESUW8puw0B0c/jGBCGGUcjYRO0Rjydi2lIPch01ai4wd5giOVU6l1MFUJ8tlZ3qMvTVlgr9RBiZyz6IvtLOREuqWMNx6zS+rqPl4tP49BlLrtM6jSU4V6cJ+qZy1piTWF3D8DL7oHLQac1tTneaipIE+ZOJfpgLcth866vTFCp2mNPagM+krlXsVIUap04gJlNDSmEerC85p+6kF9PrNFRBBLvBk592Um6AufPVTopL/xia68emY6rgfkqRmUvRqAsNFIMFIkWK5tZhzV1/y8WHNSN9RuY69tir0jRq9fANL10OM5Cwm6huKhI1u6bBTzYoVoq8DUCElaKQu1IDrpPJCa8JrZqoO+yP7syhO2Oycz80h+Gh5kTmQnfmTjo8u079KSJ/WKf0nX5okg3crfbZwOyeOe0jG8D1WFjx51GQuR4WMMbC+iFFcU8z35Rj4jBKmYu3vsqRiIeTGWxClsm49LY1TVBqgg22U4xJ472QotgRHxoU4rXuPyUAm2ySvJ7qu9ggRYlBOdIxO3n9kKO4DdSgUrMxbDylED/yYv2z/tZJvN8e5HQU3siEIvmc5fy6xchEwVYCIPwSAIuEGcbG/+i9iWZMBj+2HvWbIjl5k5KIpDTRjEh+bAnqN0USk87bXIqlYqoZf/1Vjj2XR8S6Rc0erMffdj+CGLzvtEz6KIQFQ8bkZLIrdvTBF0/5m+KkuNFUiFDWDG9ESBX5uD4RwrMilBNKb0SIFTmkPhGaOJurKbD227fHmuVhTZVbnX5NNXLJfE8/WCESJ9J3rkKkcbmFd+V3JfXLerG5jRwADu0CHt0EkB27dxCg3M5w60fwVPd9mBiQ04P3iHbpPLtBvYc+zz5p+WVCmDY3VezSAgg2XDwrajQNhIlC0aDMiLRca9jWMG5qZ7iVIK/dW/UWtC0P+n6zHZJc5sFZZus4v21feMiSJD9Xzhh67Rm87fkTbHpMCRVMEQ3yJG8rFyaKMknLbLe5XolDcs63mZC4XEA4ppbrbZztrlfm6Gw8YULmH0v113m832frsY5jrHuw5QoAr1l1op987DV6b6YZ19kDOR39jUBDUkvDVNCQ2GYxH2j107Ioqv7lB1/9pUjSwxX/Aw== -------------------------------------------------------------------------------- /demo.md: -------------------------------------------------------------------------------- 1 | **[Standalone components](#standalone-components) 1** 2 | 3 | > [Lachesis Logs (Consensus log 4 | > output)](#lachesis-logs-consensus-log-output) 2 5 | > 6 | > [Connecting](#connecting) 2 7 | > 8 | > [Display](#display) 2 9 | > 10 | > [VM Logs (Virtual Machine output)](#vm-logs-virtual-machine-output) 3 11 | > 12 | > [Connecting](#connecting-1) 3 13 | > 14 | > [Display](#display-1) 3 15 | > 16 | > [Consensus Visualizer](#consensus-visualizer) 4 17 | > 18 | > [Connecting](#connecting-2) 4 19 | > 20 | > [Display](#display-2) 4 21 | > 22 | > [Mobile Wallet](#mobile-wallet) 8 23 | > 24 | > [Download](#download) 8 25 | > 26 | > [Flow](#flow) 8 27 | > 28 | > [Signup](#signup) 8 29 | > 30 | > [Receive FTM](#receive-ftm) 11 31 | > 32 | > [Send FTM](#send-ftm) 11 33 | > 34 | > [Desktop Wallet](#desktop-wallet) 13 35 | > 36 | > [Download](#download-1) 13 37 | > 38 | > [Flow](#flow-1) 13 39 | > 40 | > [Online Store](#online-store) 15 41 | > 42 | > [Connecting](#connecting-3) 15 43 | > 44 | > [Flow](#flow-2) 15 45 | > 46 | > [Point of Sale](#point-of-sale) 24 47 | > 48 | > [Connecting](#connecting-4) 24 49 | > 50 | > [Flow](#flow-3) 24 51 | > 52 | > [Fantom Pay](#fantom-pay) 33 53 | > 54 | > [Download](#download-2) 33 55 | > 56 | > [Flow](#flow-4) 33 57 | > 58 | > [Fantom Web](#fantom-web) 33 59 | > 60 | > [Fantom Dapps](#fantom-dapps) 33 61 | 62 | Standalone components 63 | ===================== 64 | 65 | Lachesis Logs (Consensus log output) 66 | ------------------------------------ 67 | 68 | ### Connecting 69 | 70 | [http://18.191.184.199:9001/](http://18.191.184.199:9001/) 72 | 73 | 74 | 75 | Username: fantom 76 | 77 | Password: f4nt0m 78 | 79 | ### Display 80 | 81 | 82 | 83 | All log output from the Lachesis node will appear on the screen. Can 84 | demonstrate consensus events. 85 | 86 | VM Logs (Virtual Machine output) 87 | -------------------------------- 88 | 89 | ### Connecting 90 | 91 | http://18.221.128.6:9001/ 92 | 93 | 94 | 95 | Username: fantom 96 | 97 | Password: f4nt0m 98 | 99 | ### Display 100 | 101 | 102 | 103 | All VM events will be output to the screen. This is streaming from the 104 | logs. 105 | 106 | Consensus Visualizer 107 | -------------------- 108 | 109 | ### Connecting 110 | 111 | [http://ddiubnygg2i6b.cloudfront.net/dashboard](http://ddiubnygg2i6b.cloudfront.net/dashboard) 113 | 114 | Connection must be http 115 | 116 | ### Display 117 | 118 | 119 | 120 | Dashboard shows high level statistics. 121 | 122 | 123 | 124 | Visualizer shows the main chain itself. 125 | 126 | 127 | 128 | Explorer shows transaction (as above) or account (below) data. Dependent 129 | on what you search for. 130 | 131 | 132 | 133 | Mobile Wallet 134 | ------------- 135 | 136 | ### Download 137 | 138 | Android 139 | 140 | [https://www.dropbox.com/s/gx0ca2mvgr5klmd/fantomWallet\_27%3A9%3A18.apk?dl=0](https://www.dropbox.com/s/gx0ca2mvgr5klmd/fantomWallet_27%3A9%3A18.apk?dl=0) 142 | 143 | ### Flow 144 | 145 | #### Signup 146 | 147 | Screenflow below. 148 | 149 | 1. Open Application 150 | 151 | 2. Select Create Wallet 152 | 153 | 3. Copy mnemonic 154 | 155 | 4. Verify mnemonic 156 | 157 | 5. Wallet Created 158 | 159 | 160 | 161 | #### Receive FTM 162 | 163 | 1. Click rightmost bottom nav. 164 | 165 | 2. Scroll down. 166 | 167 | 3. Select Copy Address. 168 | 169 | 4. Send Address to andre@fantom.foundation to receive funds. 170 | 171 | 172 | 173 | #### Send FTM 174 | 175 | Screenflow below 176 | 177 | 1. Select middle tab 178 | 179 | 2. Select QR image in Address to send input box 180 | 181 | 3. Scan QR code 182 | 183 | 4. Select Send 184 | 185 | 5. Select Confirm 186 | 187 | 6. Wait for confirmation popup 188 | 189 | 7. Select leftmost tab 190 | 191 | 8. Confirm send transaction in transaction history 192 | 193 | 194 | 195 | Desktop Wallet 196 | -------------- 197 | 198 | ### Download 199 | 200 | [https://github.com/fantom-foundation-private/wallet/releases](https://github.com/fantom-foundation-private/wallet/releases) 202 | 203 | ### Flow 204 | 205 | 206 | 207 | ### 208 | 209 | 210 | 211 | Online Store 212 | ------------ 213 | 214 | ### Connecting 215 | 216 | [http://52.14.156.219:8081/](http://52.14.156.219:8081/) 218 | 219 | The store is currently on very low end software, so loading times are 220 | long. 221 | 222 | ### Flow 223 | 224 | 225 | 226 | Shop Now 227 | 228 | 229 | 230 | Select Item 231 | 232 | 233 | 234 | Add to cart 235 | 236 | 237 | 238 | Checkout 239 | 240 | 241 | 242 | Open Fantom Wallet 243 | 244 | 245 | 246 | Scan QR code 247 | 248 | 249 | 250 | Confirm 251 | 252 | 253 | 254 | Wait for confirmation 255 | 256 | 257 | 258 | QR code will change to paid 259 | 260 | Point of Sale 261 | ------------- 262 | 263 | ### Connecting 264 | 265 | [http://52.14.156.219](http://52.14.156.219) 267 | 268 | ### Flow 269 | 270 | 271 | 272 | Select POS 273 | 274 | 275 | 276 | - Unlisted Item 277 | 278 | 279 | 280 | Enter Price 281 | 282 | Save Changes 283 | 284 | 285 | 286 | Checkout 287 | 288 | 289 | 290 | Open Fantom Wallet 291 | 292 | 293 | 294 | Scan QR code 295 | 296 | 297 | 298 | Confirm 299 | 300 | 301 | 302 | 303 | 304 | Fantom Pay 305 | ---------- 306 | 307 | ### Download 308 | 309 | ### Flow 310 | 311 | Fantom Web 312 | ---------- 313 | 314 | Fantom Dapps 315 | ------------ 316 | -------------------------------------------------------------------------------- /storage.md: -------------------------------------------------------------------------------- 1 | **How will Fantom take care of on chain data storage?** 2 | 3 | **Background** 4 | 5 | We identify the following areas on on-chain storage 6 | 7 | 1. Smart Contract State 8 | 9 | 2. DLT State 10 | 11 | 3. Transactions 12 | 13 | 4. Immutable Data Storage 14 | 15 | 5. Mutable Data Storage 16 | 17 | **Universal State (Smart Contract State & DLT State)** 18 | 19 | State is stored on an account level. An account has ownership of its 20 | storage. This storage is captured in a trie. 21 | 22 | **Understanding Smart Contract State** 23 | 24 | Using the EVM as an example. State is a mapping between addresses 25 | (160-bit identifiers) and account states. Account states are Recursive 26 | Length Prefix (RLP) encoded data structures. This mapping is maintained 27 | in a modified Merkle Patricia tree. The root node of this structure is 28 | cryptographically dependent on all internal data. 29 | 30 | The account state consists of the following fields 31 | 32 | 1. Nonce 33 | 34 | 2. Balance 35 | 36 | 3. StorageRoot 37 | 38 | 4. CodeHash 39 | 40 | StorageRoot is a 256-bit hash of the root node of a Merkle Patricia tree 41 | which is an encoded mapping between 256-bit integer values. 42 | 43 | **Understanding DLT State** 44 | 45 | The current design of blockchains, requires replaying all data from 46 | transaction index 0 to deterministically arrive at the current state. 47 | This requires full chain data to be stored. This is how to achieve the 48 | current accurate UTXOs or State. Every transaction created needs to be 49 | stored, shared, and computed. The current distribution mechanism for 50 | this is blocks. 51 | 52 | This design has no built in archiving strategy, the ledger will grow 53 | infinitely and more storage must be consequently added. 54 | 55 | This further increases the barrier to entry leading to less 56 | decentralization. A mobile device would currently not be able to 57 | participate in the Ethereum network unless it can store 1TB worth of 58 | data. 59 | 60 | Append only ledgers grow infinitely. 61 | 62 | **Defining Immutable Data Storage** 63 | 64 | Storing data in a smart contract requires 32,000 ETH per 1GB of data (at 65 | 50 gwei). This is a fixed ratio and ignores the price of the token. We 66 | will show that the value of a token is correlated to the production 67 | value of the ecosystem. You can therefore not directly correlate 68 | production value as a fixed value towards storage. 69 | 70 | **On-Chain Storage** 71 | 72 | Storage areas identified include 73 | 74 | - Full transaction history for full nodes 75 | 76 | - Light hash history for light clients 77 | 78 | - Snapshot state storage for 79 | 80 | - Accounts 81 | 82 | - Smart Contract Code 83 | 84 | - Smart Contract State 85 | 86 | **Legacy Design** 87 | 88 | For each node; 89 | 90 | - Store all blocks 91 | 92 | - Store all transactions 93 | 94 | - Store each account state 95 | 96 | - Store each smart contract state 97 | 98 | Purpose of storing all blocks 99 | 100 | Blocks allow for anchored security, we need the sequence of blocks to be 101 | able to accurately define the sequence of transactions. Blocks allow for 102 | transaction ordering. 103 | 104 | Purpose of storing all transactions 105 | 106 | Each transaction is required to be able to arrive at the current state. 107 | We accomplish this by taking transaction index 0 and applying each 108 | transaction until index n to arrive at the current state answer. 109 | 110 | Purpose of storing account & smart contract state 111 | 112 | Each node stores each account state to be able to be 99.99% fault 113 | tolerant. Even if only 1 node remains the system will function. 114 | 115 | - Blocks are append only lists. 116 | 117 | - Transactions are append only lists. 118 | 119 | - Account size is correlated to amount of accounts on the network. 120 | 121 | - Smart contract state is variable. 122 | 123 | **Data Strategies** 124 | 125 | The following strategies have been identified 126 | 127 | - Signature snapshots 128 | 129 | - Mimblewimble (UTXO only) 130 | 131 | - State transition proofs 132 | 133 | - Data sharding 134 | 135 | **Signature snapshots** 136 | 137 | Each block contains the root signature of the account state and a list 138 | of all participating validators. Blocks are signed by all participating 139 | validators. This is considered the signed state. 140 | 141 | This can be used as the proof of consensus state to third parties. 142 | 143 | This requires a secondary structure that lists each address and their 144 | stake for each round. Cryptographically anchored to each previous round 145 | until the genesis round. 146 | 147 | The hash of the genesis round is a unique identifier of the ledger. 148 | 149 | **Mimblewimble** 150 | 151 | Bitcoin is categorized as a UTXO based system. UTXO define Unspent 152 | Transaction Outputs. An account has Inputs described as; 153 | 154 | type Transaction struct { 155 | 156 | ID \[\]byte 157 | 158 | Vin \[\]TXInput 159 | 160 | Vout \[\]TXOutput 161 | 162 | } 163 | 164 | type TXInput struct { 165 | 166 | Txid \[\]byte 167 | 168 | Vout int 169 | 170 | Signature \[\]byte 171 | 172 | PubKey \[\]byte 173 | 174 | } 175 | 176 | type TXOutput struct { 177 | 178 | Value int 179 | 180 | PubKeyHash \[\]byte 181 | 182 | } 183 | 184 | A transaction consists of Inputs (value received by the account), and 185 | outputs (values sent from the account). 186 | 187 | Alice has input 1 BTC from Bob, then Bob has output 1 BTC to Alice. If 188 | Alice then wishes to send 0.5 BTC back to Bob, and 0.5 BTC to Charlie, 189 | Alice would create a transaction with 1 BTC input from Bob, 0.5 output 190 | to Bob, and 0.5 output to Charlie. 191 | 192 | The Mimblewimble specification has the concept of UTXO compacting. 193 | Called Cut-through, it is explained as follows 194 | 195 | Blocks let miners assemble multiple transactions into a single set 196 | that’s added to the chain. In the following block representations, 197 | containing 3 transactions, we only show inputs and outputs of 198 | transactions. Inputs reference outputs they spend. An output included in 199 | a previous block is marked with a lower-case x. 200 | 201 | I1(x1) — — O1 202 | 203 | \|- O2 204 | 205 | I2(x2) — — O3 206 | 207 | I3(O2) -\| 208 | 209 | I4(O3) — — O4 210 | 211 | \|- O5 212 | 213 | We notice the two following properties: 214 | 215 | Within this block, some outputs are directly spent by included inputs 216 | (I3 spends O2 and I4 spends O3). 217 | 218 | The structure of each transaction does not actually matter. As all 219 | transactions individually sum to zero, the sum of all transaction inputs 220 | and outputs must be zero. 221 | 222 | Similarly to a transaction, all that needs to be checked in a block is 223 | that ownership has been proven (which comes from transaction kernels) 224 | and that the whole block did not add any money supply (other than what’s 225 | allowed by the coinbase). Therefore, matching inputs and outputs can be 226 | eliminated, as their contribution to the overall sum cancels out. Which 227 | leads to the following, much more compact block: 228 | 229 | I1(x1) \| O1 230 | 231 | I2(x2) \| O4 232 | 233 | \| O5 234 | 235 | Through compacting, Mimblewimble can reduce all UTXO to single pairs. 236 | This allows the chain to be drastically compacted. 237 | 238 | The same can be achieved with finalized transactions and state output. 239 | 240 | We redefine a transaction as the sum of its inputs and outputs and 241 | derive a current state. We can group all similar transactional outputs 242 | into single inputs for state transitions. 243 | 244 | If Alice sent Bob 0.5 BTC, and Charlie 0.5 BTC, followed by Bob sending 245 | 0.25BTC to Charlie, this can be represented as Alice sends 0.25 BTC to 246 | Bob and 0.75 BTC to Charlie. This is the concept behind compacting. 247 | 248 | Applied over the entire blockchain, we can considerably reduce the 249 | amount of transactions that need to be replayed to arrive at the current 250 | state, reducing size and sync speed. 251 | 252 | **State Proofs** 253 | 254 | We have computation *c(a,b)* to execute. We give *c(a,b)* to untrusted 255 | parties. We assume standard 2n/3 fault tolerance, so we send *c(a,b)* to 256 | 3 parties. 2 parties return with the same results for *c(a,b)*. We 257 | assume the result for *c(a,b)* is correct. This is verifiable computing. 258 | 259 | VM execution occurs on chain because we use multi party consensus to 260 | verify computing. We provide proof with zero knowledge that execution 261 | occurred in a trusted manner. Execution no longer needs to occur 262 | on-chain. 263 | 264 | A zero knowledge proof VM, can ensure verified computing. 265 | 266 | We have secured execution, but we still have outputs, for example ERC20 267 | addresses and balances. 268 | 269 | We knew state *s1*, and we can prove that transition occurred, we can 270 | prove *s2*. We need *s1* and transactions *tn* to prove *s2*. Given 271 | atomic state output *o* and transition proof , we can prove that 272 | participant *p* has balance *b*. 273 | 274 | To have verified data, all the chain needs to save is the atomic state 275 | output and the proof . 276 | 277 | t = (s1,tn)=s2 m 278 | 279 | setup(t) 280 | 281 | t with witness w 282 | 283 | prove(,tn,w) 284 | 285 | verify(,tn,) 286 | 287 | Consider a block, a block is our proof of transactions in it. A block is 288 | proof of a state transition. State *s1* when applied with block *bn* 289 | gives us state *s2*. So *bn* is a state transition. 290 | 291 | **Data Sharding** 292 | 293 | Goals 294 | 295 | - Reduction in data size 296 | 297 | - Sustainable data growth 298 | 299 | - Secure storage 300 | 301 | - Byzantine fault tolerant 302 | 303 | - Proof of Storage 304 | 305 | Technology 306 | 307 | - Erasure coding 308 | 309 | - Reed-Solomon codes 310 | 311 | - 100–200 shards Large-Scale Reed-Solomon Codes 312 | 313 | Erasure coding allows us to set our fault tolerance, these allow us to 314 | expand our data set with data redundancy, at an increase of storage 315 | requirement. This may seem counter intuitive, but this allows us to have 316 | a greater amount of shards in a given network. 317 | 318 | We could have erasure codes as high as 99% tolerance, which allows for 319 | 99% of all nodes in the network to disappear and we will still be able 320 | to recover our data. 321 | 322 | The erasure codes along with large scale sharding allows us to store any 323 | of the above entities across multiple participants at a fraction of the 324 | storage requirement. 325 | 326 | **Conclusion** 327 | 328 | At this point we have identified a few areas and addressed a few 329 | strategies. But there isn’t a once size fits all strategy. 330 | 331 | - To address transaction history, we adopt signed state and state 332 | > proofs. 333 | 334 | - To address smart contract state, we adopt data sharding techniques. 335 | 336 | - To address DLT state, we adopt data sharding techniques and state 337 | > proofs. 338 | 339 | - To address immutable and mutable secondary storage, we adopt a new 340 | > marketplace driven storage solution. 341 | 342 | There are more nuances here, that we will discuss in further detailed 343 | articles. 344 | -------------------------------------------------------------------------------- /gossip.md: -------------------------------------------------------------------------------- 1 | **Gossip based consensus** 2 | 3 | The concept of infinite scalability states that as node participation 4 | increases, concurrent throughput can increase. 5 | 6 | If 1 node can create a block every 1 second and a block can contain 10 7 | transactions. Then 1 node can process 10 transactions per second. 8 | 9 | By this notion, 10 nodes will process 100 transactions per second. As we 10 | increase nodes, our throughput increases. 11 | 12 | But how long does it take for the transaction from node *J* to reach 13 | node *A*? 14 | 15 | **Gossip based protocols** 16 | 17 | In gossip protocols a node can chose 1 other node to communicate with 18 | each round. There are push (node *A* sends (pushes) data to node *B*), 19 | pull (node *A* requests (pulls) data from node *B*) and push&pull (node 20 | *A* and *B* synchronize data) models. 21 | 22 | So if each round is 1 second. It would take node *J* 10 seconds to 23 | inform all the nodes of it’s data. 10 seconds until all nodes agree on 24 | the data. 100 / 10 = 10 transactions per second. 25 | 26 | We can however say that as soon as *2n/3* nodes agree, then the 27 | transactions are accepted. 100 / 7 (2 x 10 / 3) = 14 transactions per 28 | second. 29 | 30 | 10n, 100 (10 x 10) / 7 (2 x 10 / 3) = 14 tps 31 | 32 | 100n, 1,000 (100 x 10)/ 67 (2 x 100 / 3 )= 14 tps 33 | 34 | 1000n, 10,000 / 667 = 14 tps 35 | 36 | Not very “‘infinitely” scalable. 37 | 38 | The above assumes network propagation of O(n) 39 | 40 | **Network Latency simulations (same region)** 41 | 42 | 2n, 0.05s 43 | 44 | 4n, 0.2s 45 | 46 | 8n, 0.9s 47 | 48 | 16n, 2s 49 | 50 | 32n, 5s 51 | 52 | 64n, 8s 53 | 54 | 128n, 20s 55 | 56 | Adding the above back into our original simulation 57 | 58 | 2n, 20 / 0.05 = 400 59 | 60 | 4n, 40 / 0.2 = 200 61 | 62 | 8n, 80 / 0.9 = 88 63 | 64 | 16n, 160 / 2 = 80 65 | 66 | 32n, 320 / 5 = 64 67 | 68 | 64n, 640 / 8 = 80 69 | 70 | 128n, 1280 / 20 = 64 71 | 72 | Previous work has shown us; 73 | 74 | - *O(log n)* rounds for push can be applied to different graphs[1] 75 | 76 | - The upper bound for general graphs is a function of the 77 | > *conductance, φ*, of the graph. *O( φ^-1 log n)* [2] 78 | 79 | - Upper bound of *O(log n)* for natural graphs[3] 80 | 81 | - Uniform gossip with push&pull results in *O(log n)* rounds[4] 82 | 83 | - Censor-Hillel et al.[5] showed that you can inform all nodes in 84 | > *O(D + polylog(n))* rounds where *D* is the graph diameter 85 | 86 | - Haeupler[6] proposed a deterministic algorithm that completes in 87 | > *2(D + log n) log n* rounds 88 | 89 | What we expected 90 | 91 | 50n, 500 / 1.7 = 294 92 | 93 | 100n, 1000 / 2 = 500 94 | 95 | 150n, 1500 / 2.2 = 681 96 | 97 | 200n, 2000 / 2.3 = 869 98 | 99 | 100 | 101 | What actually happened. 102 | 103 | 2n, 20 / 0.05 = 400 104 | 105 | 4n, 40 / 0.2 = 200 106 | 107 | 8n, 80 / 0.9 = 88 108 | 109 | 16n, 160 / 2 = 80 110 | 111 | 32n, 320 / 5 = 64 112 | 113 | 64n, 640 / 8 = 80 114 | 115 | 128n, 1280 / 20 = 64 116 | 117 | 118 | 119 | **Definitions** 120 | 121 | A network is specified by an undirected graph G = (V, E) with node set V 122 | and edge set E. 123 | 124 | 125 | 126 | V = {1,2,3,4} 127 | 128 | E = {(1,2),(2,3),(1,4),(2,4)} 129 | 130 | 131 | 132 | V = {1,2,3} 133 | 134 | E = {(1,2)} 135 | 136 | A walk is a sequence of nodes 137 | 138 | 139 | 140 | Walk (1,2,3,4,2) 141 | 142 | A path is a walk with no repeated nodes 143 | 144 | 145 | 146 | Path (1,2,3,4) 147 | 148 | A cycle is a walk where the starting point is the ending point, and 149 | there are more than 3 nodes involved with no repeated nodes except the 150 | starting and ending point. 151 | 152 | 153 | 154 | Cycle (1,2,4,3,1) 155 | 156 | A connected graph has a path between all nodes. 157 | 158 | 159 | 160 | Connected 161 | 162 | 163 | 164 | Unconnected 165 | 166 | An acyclic graph is a graph with no cycles. 167 | 168 | A tree is an acyclic connected graph. 169 | 170 | 171 | 172 | Acyclic, connected. Tree 173 | 174 | 175 | 176 | Unconnected, not a tree. 177 | 178 | 179 | 180 | Cyclic, not a tree. 181 | 182 | **Problem** 183 | 184 | - Can we use k-local broadcast for faster consensus 185 | 186 | - Can we improve on *O(log n)* 187 | 188 | - Can we make node selection deterministic 189 | 190 | There are three specific algorithms we investigate; 191 | 192 | **Information Exchange algorithm**[7] 193 | 194 | 1. at time slot *t*, node *i* is chosen as the *initiator node* 195 | 196 | 2. node *i* broadcasts its state to all neighboring nodes, denoted by 197 | > *N(i)* 198 | 199 | 3. if *j* in *N(i) then* 200 | 201 | 4. \- *j* updates its state 202 | 203 | 5. \- all nodes in set *N(i)* send their updated states back to *i* 204 | 205 | 6. \- once *i* receives all states it computes the consensus of the 206 | > received states 207 | 208 | 7. \- *i* sends its newest state to its neighboring nodes again 209 | 210 | 8. \- all neighboring nodes *j* in *N(i)* update their states 211 | 212 | 9. end if 213 | 214 | Performance analysis of Information Exchange algorithm (LAIE) 215 | 216 | 217 | 218 | From the above we can see; 219 | 220 | - Randomized gossip *O(n² log n)* 221 | 222 | - Geographic gossip *O(n log n)* 223 | 224 | - Local Average and Information Exchange algorithm *O( n(d+1)log n / 225 | > (2+d+2(√(d-1))(d-2(√(d-1)))* 226 | 227 | **Jumping-Push-Pull in *O( √(log n))*-time**[8] 228 | 229 | 1. Each node flips a coin to decide whether it will be a leader or a 230 | > connector 231 | 232 | 2. Connectors choose leaders via five pointer jumping sub-phases (-) to 233 | > select two leader addresses 234 | 235 | 3. Leaders run the information exchange algorithm 236 | 237 | 4. Each connector opens a channel to a randomly chosen leader. Each 238 | > connector transmits once in the next round using push 239 | > communication to its other leader. Each leader sends messages by 240 | > pull to all open connections. 241 | 242 | 5. Every node performs a push&pull 243 | 244 | 245 | 246 | **Deterministic Gossip**[9] 247 | 248 | There are essentially two problems 249 | 250 | - k-local broadcast problem 251 | 252 | - Global broadcast problem 253 | 254 | In non-permissioned networks we can’t do global broadcasts since we 255 | aren’t aware of all the participants. A few strategies exists 256 | 257 | - Explore and build a virtual knowledge graph 258 | 259 | - Apply broadcast patterns on virtual knowledge graph 260 | 261 | - Use the 1-local broadcast gossip solution 262 | 263 | And we propose the k-local broadcast strategy. 264 | 265 | 266 | 267 | The above are binomial trees or i-trees. A 0-tree consists out of one 268 | root. A 1-tree consists out of two nodes and one of the nodes becomes 269 | the new root. Each tree can have multiple nodes but only a single root. 270 | 271 | 1. Each node forms it’s own i=0-tree 272 | 273 | 2. Node *A* does a push to node *B, A* will become the sub node of a 274 | > new 1 tree, with *B* as the root 275 | 276 | 3. *A* and *B* select a new neighbor whose i-tree does not intersect 277 | > with its own i-tree. 278 | 279 | 4. Repeat for all known k-participants 280 | 281 | 282 | 283 | Above we assume 32 nodes, it would take 5 steps for the iteration to 284 | complete. 285 | 286 | Phase 1: Each node selects a random neighbor and synchronizes data. This 287 | creates the 1-tree, each denoted by 1 288 | 289 | Phase 2–5: Each node selects another node that does not intersect its 290 | own i-tree. This creates the i+1-tree, each denoted by i+1 291 | 292 | The above requires us to use the full blown algorithm for the first 293 | 1-local broadcast, and then simply reuse the established links by 294 | repeating the tree-broadcast of the last iteration for the remaining 295 | local broadcasts. 296 | 297 | We need a *2 log n (log n + 1)* round for the first local broadcast, and 298 | only *2 log n* rounds for each of the *k-1* remaining ones. 299 | 300 | So for any *k* we have a deterministic gossip algorithm that runs for 301 | *2(k log n + log² n) rounds* 302 | 303 | **Analysis** 304 | 305 | We have established; 306 | 307 | - Local Average and Information Exchange algorithm *O( n(d+1)log n / 308 | > (2+d+2(√(d-1))(d-2(√(d-1)))* 309 | 310 | - Jumping-Push-Pull in *O( √(log n))*-time 311 | 312 | - k-broadcast for *2(k log n + log² n)* 313 | 314 | Each of the above have a different area of application. The Information 315 | Exchange algorithm allows us to reach a k-based consensus quickly. The 316 | jumping-push-pull allows us to gossip this information out to other 317 | leaders efficiently, and lastly the k-broadcast allows us to optimize 318 | the tree-broadcast selection for the Information Exchange algorithm. 319 | 320 | **Forming a k-event** 321 | 322 | Leader selection can be one of; 323 | 324 | - Coin toss 325 | 326 | - VRF 327 | 328 | - Cryptographic Sortition 329 | 330 | A leader runs the information exchange algorithm with tree-broadcast and 331 | consolidates all neighboring states. This creates a new event block that 332 | includes; 333 | 334 | - All validated transactions 335 | 336 | - Creator signature 337 | 338 | - Consensus timestamp 339 | 340 | - Hashes of all k-neighbor participants 341 | 342 | - Hashes of all k-neighbor unique previous event blocks 343 | 344 | This event gives us a fair bit of knowledge 345 | 346 | - k-neighbor consensus 347 | 348 | - gossip consensus information 349 | 350 | - consensus time ordering 351 | 352 | The above also allows for an unlimited message complexity, so all 353 | transactions can be exchanged between all nodes. 354 | 355 | [1] *Fountoulakis, N., Panagiotou, K., and Sauerwald, T. Ultra-fast 356 | rumor spreading in social networks. In Proc. 23rd Annual ACM-SIAM 357 | Symposium on Discrete Algorithms (2012), pp. 1642–1660.* 358 | 359 | [2] *Giakkoupis, G. Tight bounds for rumor spreading in graphs of a 360 | given conductance. In 28th International Symposium on Theoretical 361 | Aspects of Computer Science (2011), pp. 57–68* 362 | 363 | [3] *Doerr, B., Fouz, M., and Friedrich, T. Social networks spread 364 | rumors in sublogarithmic time. In Proc. 43rd Annual ACM Symposium on 365 | Theory of Computing (2011), pp. 21–30.* 366 | 367 | [4] *Doerr, B., Fouz, M., and Friedrich, T. Social networks spread 368 | rumors in sublogarithmic time. In Proc. 43rd Annual ACM Symposium on 369 | Theory of Computing (2011), pp. 21–30.* 370 | 371 | [5] *Censor-Hillel, K., Haeupler, B., Kelner, J., and Maymounkov, P. 372 | Global computation in a poorly connected world: Fast rumor spreading 373 | with no dependence on conductance. In Proc. 44th ACM Symposium on Theory 374 | of Computing (2012), pp. 961–970.* 375 | 376 | [6] *Haeupler, B. Simple, fast and deterministic gossip and rumor 377 | spreading. In Proc. 24th Annual ACM-SIAM Symposium on Discrete 378 | Algorithms, (2013), pp. 705–716.* 379 | 380 | [7] *Gang Wang, Zhiyue Wang, Jie Wu.* A local average broadcast gossip 381 | algorithm for fast global consensus over graphs*, (2017).* 382 | 383 | [8] *Chen Avin, Robert Elsasser.* Breaking the log n Barrier on Rumor 384 | Spreading*, (2015).* 385 | 386 | [9] *Bernhard Haeupler.* Simple, Fast and Deterministic Gossip and Rumor 387 | Spreading*, (2014).* 388 | -------------------------------------------------------------------------------- /dapps.md: -------------------------------------------------------------------------------- 1 | **[Setup](#setup) 0** 2 | 3 | > [Option 1: Connect directly to testnet 4 | > at;](#option-1-connect-directly-to-testnet-at) 0 5 | > 6 | > [Option 2: Host own local node;](#option-2-host-own-local-node) 1 7 | > 8 | > [Step 0 Docker](#step-0-docker) 1 9 | > 10 | > [Step 1 Installing Go (Ubuntu)](#step-1-installing-go-ubuntu) 1 11 | > 12 | > [Step 1 Setup](#step-1-setup) 1 13 | > 14 | > [Step 2 Clone Repo](#step-2-clone-repo) 1 15 | > 16 | > [Step 3 (Optional, hard mode)](#step-3-optional-hard-mode) 2 17 | > 18 | > [Running the node](#running-the-node) 3 19 | > 20 | > [Example Commands](#example-commands) 4 21 | 22 | **[HTTP API](#http-api) 4** 23 | 24 | > [Get controlled accounts](#get-controlled-accounts) 4 25 | > 26 | > [Get any account](#get-any-account) 4 27 | > 28 | > [Send transactions from controlled 29 | > accounts](#send-transactions-from-controlled-accounts) 5 30 | > 31 | > [Get Transaction receipt](#get-transaction-receipt) 5 32 | > 33 | > [Send raw signed transactions](#send-raw-signed-transactions) 5 34 | 35 | **[Deploying a contract](#deploying-a-contract) 7** 36 | 37 | > [Create bytecode from solidity file](#create-bytecode-from-solidity) 7 38 | > 39 | > [Get Contract Address](#get-contract-address) 8 40 | > 41 | > [Call the Deployed Contract](#call-the-deployed-contract) 9 42 | 43 | Setup 44 | ===== 45 | 46 | Option 1: Connect directly to testnet at; 47 | ----------------------------------------- 48 | 49 | http://18.221.128.6:8080 50 | 51 | Example call; [http://18.221.128.6:8080/account/0xFD00A5fE03CB4672e4380046938cFe5A18456Df4](http://18.221.128.6:8080/account/0xFD00A5fE03CB4672e4380046938cFe5A18456Df4) 53 | 54 | Option 2: Host own local node; 55 | ------------------------------ 56 | 57 | ### Step 0 Docker 58 | 59 | Create an 3 node lachesis cluster with: 60 | 61 | n=3 BUILD\_DIR="$PWD" ./docker/builder/scale.bash 62 | 63 | - Docker 64 | 65 | - jq 66 | 67 | - Bash 68 | 69 | - glider base Docker Image with: 70 | 71 | - git clone https://github.com/Fantom-foundation/evm \# or \`cd 72 | > $GOPATH/src/github.com/Fantom-foundation\` 73 | > cd evm/docker/glider 74 | > docker build --compress --squash --force-rm --tag "${PWD\#\#\*/}" 75 | > . 76 | 77 | - Go 78 | 79 | - [ class="underline">batch-ethkey](https://github.com/SamuelMarks/batch-ethkey) 81 | > with: go get -v github.com/SamuelMarks/batch-ethkey 82 | 83 | Step 1 Installing Go (Ubuntu) 84 | ----------------------------- 85 | 86 | ### Step 1 Setup 87 | 88 | sudo apt-get update 89 | 90 | sudo apt-get -y upgrade 91 | 92 | sudo curl -O 93 | https://storage.googleapis.com/golang/go1.9.1.linux-amd64.tar.gz 94 | 95 | sudo tar -xvf go1.9.1.linux-amd64.tar.gz 96 | 97 | sudo mv go /usr/local 98 | 99 | sudo nano \~/.profile 100 | 101 | export PATH=$PATH:/usr/local/go/bin 102 | 103 | source \~/.profile 104 | 105 | ### Step 2 Clone Repo 106 | 107 | mkdir -p $GOPATH/src/github.com/Fantom-foundation/ 108 | 109 | cd $GOPATH/src/github.com/Fantom-foundation 110 | 111 | git clone https://github.com/Fantom-foundation/lachesis.git 112 | 113 | export GOPATH=$HOME/work 114 | 115 | cd $GOPATH/src/github.com/Fantom-foundation/lachesis 116 | 117 | curl https://glide.sh/get \| sh 118 | 119 | glide install 120 | 121 | ### Step 3 (Optional, hard mode) 122 | 123 | sudo apt-get update 124 | 125 | sudo apt-get -y upgrade 126 | 127 | sudo curl -O 128 | https://storage.googleapis.com/golang/go1.9.1.linux-amd64.tar.gz 129 | 130 | sudo tar -xvf go1.9.1.linux-amd64.tar.gz 131 | 132 | sudo mv go /usr/local 133 | 134 | sudo nano \~/.profile 135 | 136 | export PATH=$PATH:/usr/local/go/bin 137 | 138 | source \~/.profile 139 | 140 | mkdir $HOME/work 141 | 142 | export GOPATH=$HOME/work 143 | 144 | mkdir -p $HOME/work/src/github.com/user/ 145 | 146 | cd $HOME/work/src/github.com/user/ 147 | 148 | git clone https://github.com/Fantom-foundation/lachesis.git 149 | 150 | apt-get install -y build-essential 151 | 152 | \#Lachesis 153 | 154 | go get github.com/dgraph-io/badger 155 | 156 | go get github.com/sirupsen/logrus 157 | 158 | go get gopkg.in/urfave/cli.v1 159 | 160 | make build 161 | 162 | \#Lachesis 163 | 164 | ./build/lachesis keygen 165 | 166 | mkdir -p /root/.lachesis/ 167 | 168 | vi /root/.lachesis/priv\_key.pem 169 | 170 | vi /root/.lachesis/peers.json 171 | 172 | \[ 173 | 174 | { 175 | 176 | "NetAddr":"ip:12000", 177 | 178 | "PubKeyHex":"0x0448C9212873C76DE0086DA680F9329735C40674B5FA05105886548B217273B0AFA02D73157F 179 | 180 | 4D96DACFE1D9E44DBB2608F5C60D037743DB18567B82D077CBAE40" 181 | 182 | }, 183 | 184 | { 185 | 186 | "NetAddr":"ip:12000", 187 | 188 | "PubKeyHex":"0x04C503A238046D9095B548E61939CA58BE926C6809F7205CD2D671A88C4E8369754ADE343FB 189 | 190 | B4FBE9A46118EB549753B76B18243369E0475A319989F06879CFE19" 191 | 192 | }, 193 | 194 | { 195 | 196 | "NetAddr":"ip:12000", 197 | 198 | "PubKeyHex":"0x046A584F2FBDF61A36B8D30461C9285B817F60271D41B7B7EC445EF73DD2B363B1F782D5FE9 199 | 200 | 6D3D08B71750F4D07CC137AE7AD9A95574791737E6E407880015B3A" 201 | 202 | } 203 | 204 | \] 205 | 206 | #### Running the node 207 | 208 | The default data dir is currently; 209 | 210 | $HOME/.lachesis/ 211 | 212 | In this folder it expects two files; 213 | 214 | priv\_key.pem 215 | 216 | peers.json 217 | 218 | peers.json is the current node list (completely permissioned system 219 | currently, it is defined as per below, the 220 | 221 | PubKeyHex is the public key (with 0x) that corresponds to the private 222 | key found in priv\_key.pem 223 | 224 | \[ 225 | 226 | { 227 | 228 | "NetAddr":"ip:12000", 229 | 230 | "PubKeyHex":"0x0448C9212873C76DE0086DA680F9329735C40674B5FA05105886548B217273B0AFA02D73157F 231 | 232 | 4D96DACFE1D9E44DBB2608F5C60D037743DB18567B82D077CBAE40" 233 | 234 | }, 235 | 236 | { 237 | 238 | "NetAddr":"ip:12000", 239 | 240 | "PubKeyHex":"0x04C503A238046D9095B548E61939CA58BE926C6809F7205CD2D671A88C4E8369754ADE343FB 241 | 242 | B4FBE9A46118EB549753B76B18243369E0475A319989F06879CFE19" 243 | 244 | }, 245 | 246 | { 247 | 248 | "NetAddr":"ip:12000", 249 | 250 | "PubKeyHex":"0x046A584F2FBDF61A36B8D30461C9285B817F60271D41B7B7EC445EF73DD2B363B1F782D5FE9 251 | 252 | 6D3D08B71750F4D07CC137AE7AD9A95574791737E6E407880015B3A" 253 | 254 | } 255 | 256 | \] 257 | 258 | To run the nodes you execute; 259 | 260 | \#service node 261 | 262 | ./build/lachesis run -node\_addr="ip:port" -service\_addr="ip:port" 263 | 264 | \#proxy node 265 | 266 | ./build/lachesis run -node\_addr="ip:port" -proxy\_addr="ip:port" 267 | -client\_addr="ip:port" 268 | 269 | #### Example Commands 270 | 271 | \#service node 272 | 273 | ./build/lachesis run -node\_addr="ip:12000" -service\_addr="ip:8000" 274 | 275 | \#proxy node 276 | 277 | ./build/lachesis run -node\_addr="ip:12000" -proxy\_addr="ip:9000" 278 | -client\_addr="ip:9000" 279 | 280 | You can subscribe to service\_addr for http requests, so in above 281 | example [http://ip:8000/stats](http://ip:8000/stats) 283 | 284 | HTTP API 285 | ======== 286 | 287 | Get controlled accounts 288 | ----------------------- 289 | 290 | This endpoint returns all the accounts that are controlled by the evm 291 | instance. These are the accounts whose private keys are present in the 292 | keystore. example: 293 | 294 | 295 | 296 | Get any account 297 | --------------- 298 | 299 | This method allows retrieving the information about any account, not 300 | just the ones whose keys are included in the keystore. 301 | 302 | 303 | 304 | Send transactions from controlled accounts 305 | ------------------------------------------ 306 | 307 | Send a transaction from an account controlled by the evm instance. The 308 | transaction will be signed by the service since the corresponding 309 | private key is present in the keystore. example: Send Ether between 310 | accounts 311 | 312 | 313 | 314 | Get Transaction receipt 315 | ----------------------- 316 | 317 | Example: 318 | 319 | 320 | 321 | Send raw signed transactions 322 | ---------------------------- 323 | 324 | Most of the time, one will require to send transactions from accounts 325 | that are not controlled by the evm instance. The transaction will be 326 | assembled, signed and encoded on the client side. The resulting raw 327 | signed transaction bytes can be submitted to evm through the /rawtx 328 | endpoint. example: 329 | 330 | 331 | 332 | Below is how to interact, otherwise standard EVM rules. 333 | 334 | // node.js 335 | 336 | const axios = require('axios'); 337 | 338 | const EthereumTx = require('ethereumjs-tx') 339 | 340 | const privateKey = Buffer.from('<private key>', 'hex') 341 | 342 | const txParams = { 343 | 344 | nonce: '0x00', 345 | 346 | gasPrice: '0x000000000001', 347 | 348 | gasLimit: '0x27100', 349 | 350 | to: '0xFD00A5fE03CB4672e4380046938cFe5A18456Df4', 351 | 352 | value: '0x00', 353 | 354 | data: '0x', 355 | 356 | // EIP 155 chainId - mainnet: 1, ropsten: 3 357 | 358 | chainId: 1 359 | 360 | } 361 | 362 | const tx = new EthereumTx(txParams) 363 | 364 | tx.sign(privateKey) 365 | 366 | const serializedTx = tx.serialize() 367 | 368 | const hexTx = '0x' + serializedTx.toString('hex') 369 | 370 | axios.post('[http://ip:port/sendRawTransaction](http://18.221.128.6:8080/sendRawTransaction)', 372 | hexTx) 373 | 374 | .then(function (response) { 375 | 376 | console.log(response.data); 377 | 378 | }) 379 | 380 | .catch(function (error) { 381 | 382 | console.log(error); 383 | 384 | }); 385 | 386 | //50c4bf4dde1f383a172f52cb4624f089f685e67e00c6741a3ae03826c99cf082:0xFD00A5fE03CB4672e4380046938cFe5A18456Df4 387 | 388 | //7c9d2f34f5869204fe8232442bc2280a613601783fab2b936cf91a054668537a:0xfd9AB87eCEdC912A63f5B8fa3b8d7667d33Fd981 389 | 390 | // [http://](http://18.221.128.6:8080/account/629007eb99ff5c3539ada8a5800847eacfc25727)[ip:port](http://18.221.128.6:8080/sendRawTransaction)/account/629007eb99ff5c3539ada8a5800847eacfc25727 392 | 393 | // http://ip:port/sendRawTransaction 394 | 395 | // [http://](http://18.221.128.6:8080/transactions)[ip:port](http://18.221.128.6:8080/sendRawTransaction)/transactions 397 | 398 | // [http://](http://18.221.128.6:8080/accounts)[ip:port](http://18.221.128.6:8080/sendRawTransaction)/accounts 400 | 401 | // [http://](http://18.221.128.6:8080/transaction/%7B%7D)[ip:port](http://18.221.128.6:8080/sendRawTransaction)/transaction/{} 403 | 404 | // [http://](http://18.221.128.6:8080/account/%7B%7D)[ip:port](http://18.221.128.6:8080/sendRawTransaction)/account/{} 406 | 407 | /\* 408 | 409 | [http://](http://18.221.128.6:8080/account/0xFD00A5fE03CB4672e4380046938cFe5A18456Df4)[ip:port](http://18.221.128.6:8080/sendRawTransaction)/account/0xFD00A5fE03CB4672e4380046938cFe5A18456Df4 411 | 412 | {"address":"0xFD00A5fE03CB4672e4380046938cFe5A18456Df4","balance":9999790000000000000000,"nonce":1} 413 | 414 | [http://](http://18.221.128.6:8080/transaction/0x68a07a9dc6ff0052e42f4e7afa117e90fb896eda168211f040da69606a2aeddc)[ip:port](http://18.221.128.6:8080/sendRawTransaction)/transaction/0x68a07a9dc6ff0052e42f4e7afa117e90fb896eda168211f040da69606a2aeddc 416 | 417 | {"root":"0x7ed3e21533e05c18ded09e02d7bf6bf812c218a3a7af8c6b5cc23b5cb4951069","transactionHash":"0x68a07a9dc6ff0052e42f4e7afa117e90fb896eda168211f040da69606a2aeddc","from":"0xfd00a5fe03cb4672e4380046938cfe5a18456df4","to":"0xfd00a5fe03cb4672e4380046938cfe5a18456df4","gasUsed":21000,"cumulativeGasUsed":21000,"contractAddress":"0x0000000000000000000000000000000000000000","logs":\[\],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","failed":false} 418 | 419 | function getNonce(tx) { 420 | 421 | axios.get('[http://](http://18.221.128.6:8080/account/'+tx.from)[ip:port](http://18.221.128.6:8080/sendRawTransaction)[/account/'+tx.from](http://18.221.128.6:8080/account/'+tx.from)) 423 | 424 | .then(function (response) { 425 | 426 | tx.nonce = response.data.nonce 427 | 428 | generateRawTx(tx, priv) 429 | 430 | }) 431 | 432 | .catch(function (error) { 433 | 434 | console.log(error); 435 | 436 | }); 437 | 438 | } 439 | 440 | \*/ 441 | 442 | Deploying a contract 443 | ==================== 444 | 445 | Create bytecode from solidity 446 | ----------------------------- 447 | 448 | JSONbig = require('json-bigint'); 449 | 450 | fs = require('fs') 451 | 452 | solc = require('solc') 453 | 454 | Web3 = require('web3') 455 | 456 | web3 = new Web3() 457 | 458 | function Contract(file, name) { 459 | 460 | this.file = file 461 | 462 | this.name = ':'+name 463 | 464 | this.bytecode = '' 465 | 466 | this.abi = '' 467 | 468 | } 469 | 470 | Contract.prototype.compile = function() { 471 | 472 | input = fs.readFileSync(this.file) 473 | 474 | output = solc.compile(input.toString(), 1) 475 | 476 | console.log('compile output', output) 477 | 478 | this.bytecode = output.contracts\[this.name\].bytecode 479 | 480 | this.abi = output.contracts\[this.name\].interface 481 | 482 | this.w3 = web3.eth.contract(JSONbig.parse(this.abi)).at(''); 483 | 484 | } 485 | 486 | const contract = new Contract('./helloWorld.sol', 'HelloWorld') 487 | 488 | contract.compile() 489 | 490 | const EthereumTx = require('ethereumjs-tx') 491 | 492 | const privateKey = Buffer.from('<private\_key>', 'hex') 493 | 494 | const txParams = { 495 | 496 | from: '0x5A7fcbE8e848E957166631E5DAbD683210f06E7c', 497 | 498 | value: 0, 499 | 500 | nonce: nonce, 501 | 502 | chainId:1, 503 | 504 | gas: 1000000, 505 | 506 | gasPrice:0, 507 | 508 | data: '0x' + contract.bytecode + constructorParams, 509 | 510 | } 511 | 512 | const tx = new EthereumTx(txParams) 513 | 514 | tx.sign(privateKey) 515 | 516 | const serializedTx = tx.serialize() 517 | 518 | const hexTx = '0x' + serializedTx.toString('hex') 519 | 520 | axios.post('http://18.224.109.107:8080/sendRawTransaction', hexTx) 521 | 522 | .then(function (response) { 523 | 524 | console.log(response.data); 525 | 526 | }) 527 | 528 | .catch(function (error) { 529 | 530 | console.log(error); 531 | 532 | }); 533 | 534 | Get Contract Address 535 | -------------------- 536 | 537 | Call [http://18.224.109.107:8080/tx/0x81163ffaa2e05720bfb772e58edec81bf5640f9dbebe0105720cfeb9066256da](http://18.224.109.107:8080/tx/0x81163ffaa2e05720bfb772e58edec81bf5640f9dbebe0105720cfeb9066256da) 539 | 540 | {"root":"0x3c7b6e8900b625a5c0f5610ff1a6414ae078f6f9fbe3f69511074b642f7a30c8","transactionHash":"0x81163ffaa2e05720bfb772e58edec81bf5640f9dbebe0105720cfeb9066256da","from":"0x5a7fcbe8e848e957166631e5dabd683210f06e7c","to":null,"value":0,"gas":1000000,"gasUsed":242199,"gasPrice":0,"cumulativeGasUsed":242199,"contractAddress":"0x8efe306de45fe1f3cdf0338c8d5d1c30f60ba286","logs":\[\],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","error":"","failed":false} 541 | 542 | contractAddres contains the newly created address. 543 | 544 | Call the Deployed Contract 545 | -------------------------- 546 | 547 | const contract = new Contract('./helloWorld.sol', 'HelloWorld') 548 | 549 | contract.compile() 550 | 551 | const callData = contract.w3.helloWorld.getData() 552 | 553 | //Note the function name of the solidity function 554 | 555 | const tx = { 556 | 557 | from: '<any from address>', 558 | 559 | value:0, 560 | 561 | to: '<contract\_address>', 562 | 563 | data: callData, 564 | 565 | } 566 | 567 | axios.post('http://18.224.109.107:8080/call', stx) 568 | 569 | .then(function (response) { 570 | 571 | console.log(response.data); 572 | 573 | hexRes = Buffer.from(response.data.data).toString() 574 | 575 | // If you want to parse the results <function\_name> 576 | 577 | unpacked = contract.parseOutput('helloWorld', hexRes) 578 | 579 | }) 580 | 581 | .catch(function (error) { 582 | 583 | console.log(error); 584 | 585 | }); 586 | -------------------------------------------------------------------------------- /contrib.md: -------------------------------------------------------------------------------- 1 | **[Dr Ahn Byung Ik - CEO](#dr-ahn-byung-ik---ceo) 3** 2 | 3 | > [Bio](#bio) 3 4 | > 5 | > [Career](#career) 3 6 | > 7 | > [Education](#education) 4 8 | > 9 | > [Awards](#awards) 4 10 | > 11 | > [Publications](#publications) 4 12 | 13 | **[Hyochang Nam - CDO](#hyochang-nam---cdo) 4** 14 | 15 | > [Career](#career-1) 4 16 | > 17 | > [Education](#education-1) 4 18 | 19 | **[Michael Kong - CIO](#michael-kong---cio) 4** 20 | 21 | > [Career](#career-2) 4 22 | > 23 | > [Education](#education-2) 5 24 | > 25 | > [Awards](#awards-1) 5 26 | > 27 | > [Publications](#publications-1) 5 28 | 29 | **[Aleksander (Alex) Kampa - 30 | Researcher](#aleksander-alex-kampa---researcher) 5** 31 | 32 | > [Bio](#bio-1) 5 33 | > 34 | > [Career](#career-3) 5 35 | > 36 | > [Education](#education-3) 5 37 | > 38 | > [Publications](#publications-2) 6 39 | 40 | **[Dr Stephane Vincent - Applied Cryptography and Blockchain Research 41 | Scientist](#dr-stephane-vincent---applied-cryptography-and-blockchain-research-scientist) 42 | 6** 43 | 44 | > [Bio](#bio-2) 6 45 | > 46 | > [Career](#career-4) 6 47 | > 48 | > [Education](#education-4) 6 49 | 50 | **[Dr Sang-Min Choi - Senior Principal 51 | Researcher](#dr-sang-min-choi---senior-principal-researcher) 6** 52 | 53 | > [Bio](#bio-3) 6 54 | > 55 | > [Career](#career-5) 7 56 | > 57 | > [Education](#education-5) 7 58 | > 59 | > [Publications](#publications-3) 7 60 | 61 | **[Dr Jiho Park - Senior Principal 62 | Researcher](#dr-jiho-park---senior-principal-researcher) 7** 63 | 64 | > [Career](#career-6) 7 65 | > 66 | > [Education](#education-6) 7 67 | 68 | **[Dr Quan Nguyen - Software Development 69 | Specialist](#dr-quan-nguyen---software-development-specialist) 7** 70 | 71 | > [Bio](#bio-4) 7 72 | > 73 | > [Career](#career-7) 8 74 | > 75 | > [Education](#education-7) 8 76 | 77 | **[Samuel Marks - Infrastructure 78 | Engineer](#samuel-marks---infrastructure-engineer) 8** 79 | 80 | > [Bio](#bio-5) 8 81 | > 82 | > [Career](#career-8) 9 83 | > 84 | > [Education](#education-8) 9 85 | > 86 | > [Publications](#publications-4) 9 87 | 88 | **[Maxim Zakharov - Golang Engineer](#maxim-zakharov---golang-engineer) 89 | 9** 90 | 91 | > [Bio](#bio-6) 9 92 | > 93 | > [Career](#career-9) 9 94 | > 95 | > [Education](#education-9) 9 96 | 97 | **[Joseph Gentle - Golang Engineer](#joseph-gentle---golang-engineer) 98 | 10** 99 | 100 | > [Career](#career-10) 10 101 | > 102 | > [Education](#education-10) 10 103 | 104 | **[Fletcher Haynes - Golang 105 | Engineer](#fletcher-haynes---golang-engineer) 10** 106 | 107 | > [Career](#career-11) 10 108 | > 109 | > [Education](#education-11) 10 110 | 111 | **[Md Samiul Alim Sakib - Golang 112 | Engineer](#md-samiul-alim-sakib---golang-engineer) 10** 113 | 114 | > [Bio](#bio-7) 10 115 | > 116 | > [Career](#career-12) 10 117 | > 118 | > [Education](#education-12) 11 119 | 120 | **[Zhiyi Wei - Golang Engineer](#zhiyi-wei---golang-engineer) 11** 121 | 122 | > [Bio](#bio-8) 11 123 | > 124 | > [Career](#career-13) 11 125 | > 126 | > [Education](#education-13) 11 127 | 128 | **[Bastian Wieck - Golang Engineer](#bastian-wieck---golang-engineer) 129 | 12** 130 | 131 | > [Bio](#bio-9) 12 132 | > 133 | > [Go, Python, C\# and Java Developer, shaping the future one byte at 134 | > the 135 | > time](#go-python-c-and-java-developer-shaping-the-future-one-byte-at-the-time) 136 | > 12 137 | > 138 | > [Career](#career-14) 12 139 | > 140 | > [Education](#education-14) 12 141 | 142 | **[Roan Brand - Golang Engineer](#roan-brand---golang-engineer) 12** 143 | 144 | > [Career](#career-15) 12 145 | > 146 | > [Education](#education-15) 12 147 | 148 | **[Brian Acton - Golang Engineer](#brian-acton---golang-engineer) 13** 149 | 150 | > [Bio](#bio-10) 13 151 | > 152 | > [Career](#career-16) 13 153 | 154 | **[Peter Badenhorst - Golang 155 | Engineer](#peter-badenhorst---golang-engineer) 13** 156 | 157 | > [Career](#career-17) 13 158 | 159 | **[Jong Chul Park - Middleware Java 160 | Engineer](#jong-chul-park---middleware-java-engineer) 13** 161 | 162 | > [Career](#career-18) 13 163 | > 164 | > [Education](#education-16) 13 165 | > 166 | > [Publications](#publications-5) 13 167 | 168 | **[Kang Ho Kim - Middleware Java 169 | Engineer](#kang-ho-kim---middleware-java-engineer) 14** 170 | 171 | > [Career](#career-19) 14 172 | > 173 | > [Education](#education-17) 14 174 | 175 | **[Jung Hwa Ye - Middleware Java 176 | Engineer](#jung-hwa-ye---middleware-java-engineer) 14** 177 | 178 | > [Career](#career-20) 14 179 | > 180 | > [Education](#education-18) 14 181 | 182 | **[Chan Yeul Jo - Middleware Java 183 | Engineer](#chan-yeul-jo---middleware-java-engineer) 14** 184 | 185 | > [Career](#career-21) 14 186 | > 187 | > [Education](#education-19) 14 188 | 189 | Dr Ahn Byung Ik - CEO 190 | ===================== 191 | 192 | Bio 193 | --- 194 | 195 | Expert in LBS/ Blockchain & Distributed System/ Social Network & 196 | Computing/ Mobile/ O2O technology of Food Tech. Worked as a research 197 | engineer after receiving PhD from Yonsei University. Starting from KT 198 | in-house venture in 1998, founded LBS(Location Based System) Company 199 | ‘Point-I’ in 2000 and sold the business after the IPO. Currently, the 200 | CEO and the founder of foodtech O2O company Siksin Co., Ltd. Also, the 201 | president of ‘Korea Foodtech Association’, a board member of Korea LBS 202 | Industry association, and ‘Korea Internet Experts’ Association.’ 203 | 204 | Career 205 | ------ 206 | 207 | Founder and the CEO of FANTOM Foundation. 2018 \~ present 208 | 209 | Founder and the CEO of Siksin Co., Ltd. 2010 \~ present 210 | 211 | President of Korea Foodtech Association 2017 \~ present 212 | 213 | Adjunct professor of Konkuk grad school (Electronic, Information & 214 | Communication engineering) 2010 \~ 2016 215 | 216 | Contributes a column ‘Ahn Byungik’s Smart life’ every month – The 217 | Fortune Korea 2015.1 \~ present 218 | 219 | Contributes a column ‘Uber insight’ – MK newspaper 2016 \~ present 220 | 221 | Chairperson of the LBS Industry association’s service committee 2003 \~ 222 | present 223 | 224 | Board member of the ‘Korea Internet Experts’ Association’ 2015 \~ 225 | present 226 | 227 | CEO and the founder of Point-I Co., Ltd. 2000 \~ 2009 228 | 229 | Research engineer of KT(Korea telecom) 1993 \~ 1999 230 | 231 | Achieved Information Processing Technology license 1997 232 | 233 | Education 234 | --------- 235 | 236 | PhD. Computer Science – Yonsei Univ. 2007 237 | 238 | Completed AMP – Seoul National Univ. business school 2008 239 | 240 | Completed SEIT – Stanford Univ. business school 2002 241 | 242 | Awards 243 | ------ 244 | 245 | Commendation from the President of Korea Communication Commission 246 | regarding the dedication on LBS 2011 247 | 248 | Commendation from the Prime Minister of Korea 2007 249 | 250 | Publications 251 | ------------ 252 | 253 | ‘Connector – the controlling power of the world’ – Youngrim Cardinal, 254 | 2016 255 | 256 | Hyochang Nam - CDO 257 | ================== 258 | 259 | Career 260 | ------ 261 | 262 | Team Lead at SECUI.COM. 2001 \~ 2018 263 | 264 | Education 265 | --------- 266 | 267 | PhD, Computer Engineering – Pohang University of Science and Technology 268 | 2003 269 | 270 | Michael Kong - CIO 271 | ================== 272 | 273 | Career 274 | ------ 275 | 276 | Advisor to Enosi Foundation. 2018 \~ present 277 | 278 | Chief Information Officer at Fantom Foundation 2018 \~ present 279 | 280 | Chief Technology Officer at Digital Currency Holdings 2017 \~ present 281 | 282 | Developer at Block8 2017 \~ 2017 283 | 284 | Chief Technology Officer at myStake 2017 \~ 2017 285 | 286 | Director at Aiziko Pty. Ltd 2015 \~ 2017 287 | 288 | Chief Technology Officer at Liberte & Co 2016 \~ 2016 289 | 290 | Co-founder of Horyzon Pty. Ltd 2016 \~ 2016 291 | 292 | Education 293 | --------- 294 | 295 | Information Technology, First Class Honours – University of Sydney 2017 296 | 297 | Awards 298 | ------ 299 | 300 | Microsoft Research Prize for Senior Software Development Projects 2017 301 | 302 | RAP Jackson Scholarship, Commonwealth Bank of Australia 2012 303 | 304 | UNSW Co-op Scholarship in Business Information Technology 2012 305 | 306 | Publications 307 | ------------ 308 | 309 | Vandal: A scalable Security Analysis Framework for Smart Contracts 2018 310 | 311 | MadMax: Surviving Out-of-Gas Conditions in Ethereum Smart Contracts 2018 312 | 313 | Aleksander (Alex) Kampa - Researcher 314 | ==================================== 315 | 316 | Bio 317 | --- 318 | 319 | Alex is a blockchain developer and economist. He is currently the 320 | director of Sikoba Ltd, a peer-to-peer credit lending and rating system. 321 | Alex was also a part-time consultant for the European Union Commission 322 | on blockchain-related subjects. 323 | 324 | Founder of Sikoba ("home of the IOU economy") - building a decentralised 325 | peer-to-peer IOU platform with blockchain technology. Researcher in 326 | monetary theory. Senior Technical Expert at the European Commission's 327 | Blockchain Competence Centre. 328 | 329 | Career 330 | ------ 331 | 332 | Director at Sikoba Ltd 2016 \~ present 333 | 334 | Senior Technical Expert - Blockchain Competence Centre for European 335 | Commission DIGIT 2017 \~ present 336 | 337 | Researcher at New Money Hub 2016 \~ present 338 | 339 | IT and finance consultant for Risk Engine 2007 \~ 2016 340 | 341 | Consultant at Lombard Risk 2007 \~ 2016 342 | 343 | Education 344 | --------- 345 | 346 | Master’s Degree, Statistics – Texas A&M University 1988 347 | 348 | Engineer’s Degree, Engineering and Economics – Ecole Centrale Paris 1987 349 | 350 | Mathematics and science – Lycee Sainte-Genevieve 1984 351 | 352 | Publications 353 | ------------ 354 | 355 | Money, Credit Conversion and the legacy of Mitchell-Innes 2017 356 | 357 | Dr Stephane Vincent - Applied Cryptography and Blockchain Research Scientist 358 | ============================================================================ 359 | 360 | Bio 361 | --- 362 | 363 | Stephane was a Postdoctoral Researcher at the University of Utah and is 364 | currently a cryptography and blockchain researcher at nChain. He is the 365 | co-author of a paper titled “NECTAR: Non-Interactive Smart Contract 366 | Protocol using Blockchain Technology”, which describes the 367 | implementation of new techniques for smart contract execution, improving 368 | their performance and usability. Stephane is also a blockchain 369 | consultant to the European Union Commission. At Fantom, Stephane will be 370 | leading our verified computing initiative. 371 | 372 | My primary interest is in the application of cryptographic techniques 373 | and blockchain technologies to real-world problems. 374 | 375 | Career 376 | ------ 377 | 378 | Blockchain Consultant for European Commission. 2018 \~ present 379 | 380 | Applied Cryptography and Blockchain Research Scientist for nChain. 2016 381 | \~ 2018 382 | 383 | Research Associate at DESY. 2011 \~ 2016 384 | 385 | Postdoctoral Researcher at University of Utah. 2008 \~ 2011 386 | 387 | Education 388 | --------- 389 | 390 | PhD. Physics – Universite Nice Sophia Antipolis. 391 | 392 | Dr Sang-Min Choi - Senior Principal Researcher 393 | ============================================== 394 | 395 | Bio 396 | --- 397 | 398 | Research Area: Recommender Systems, Algorithm Design 399 | 400 | Keyword: Artificial Intelligence, Machine Learning, Deep Learning, 401 | Algorithm, Social Network, Blockchain, DAG, Consensus Algorithm 402 | 403 | Laboratory: Theory of Computation Lab in Yonsei University, Seoul, Korea 404 | 405 | Google Scholar Citations: 406 | https://scholar.google.com/citations?user=o8v\_AAcAAAAJ 407 | 408 | Career 409 | ------ 410 | 411 | Senior Principal Researcher at Fantom Foundation.. 2018 \~ present 412 | 413 | Postdoctoral Researcher at Yonsei University 2018 \~ present 414 | 415 | Education 416 | --------- 417 | 418 | PhD. Computer Science – Yonsei Univ. 2015 419 | 420 | Publications 421 | ------------ 422 | 423 | GSEH: A Novel Approach to Select Prostate Cancer-Associated Genes Using 424 | Gene Expression Heterogeneity 2016 425 | 426 | A Recommendation Model Using the Bandwagon Effect for E-Marketing 427 | Purposes in IoT 2015 428 | 429 | Representative Reviewers for Internet Social Media 2013 430 | 431 | A Movie Recommendation Algorithm based on Genre Correlations 2012 432 | 433 | Dr Jiho Park - Senior Principal Researcher 434 | ========================================== 435 | 436 | Career 437 | ------ 438 | 439 | Senior Principal Researcher at Fantom Foundation.. 2018 \~ present 440 | 441 | Postdoctoral Researcher at Yonsei University 2018 \~ present 442 | 443 | Education 444 | --------- 445 | 446 | PhD. Computer Science – Yonsei Univ. 2015 447 | 448 | Dr Quan Nguyen - Software Development Specialist 449 | ================================================ 450 | 451 | Bio 452 | --- 453 | 454 | Quan is a software engineer and researcher. He was previously a 455 | Postdoctoral researcher at the University of Sydney, where his fields 456 | were in Graph Drawing, InfoVis, Data Mining and Visual Analytics. His 457 | PhD thesis is titled “Models and Methods for Big graph visualizations.” 458 | He has won multiple mathematics competitions and awards for his 459 | research. Quan was also a software engineer at IBM, working on WCM, 460 | cloud computing, and RESTful web services. Prior to that, he worked on 461 | the Smarts market surveillance system with NASDAQ. 462 | 463 | Experience in R&D with a demonstrated history of working in the higher 464 | education industry. Skilled in Java, C++, Js, C, Python. Strong research 465 | professional with a PhD focused in Graph Visualization from University 466 | of Sydney. 467 | 468 | Career 469 | ------ 470 | 471 | Software Development Specialist at Fantom Foundation. 2018 \~ present 472 | 473 | Postdoctoral Researcher at University of Sydney. 2016 \~ 2018 474 | 475 | Software Engineer at IBM. 2013 \~ 2016 476 | 477 | Software Developer at Capital Markets CRC Limited. 2011 \~ 2014 478 | 479 | Software Engineer at Nasdaq. 2010 \~ 2011 480 | 481 | Software Engineer at Canon CISRA. 2009 \~ 2010 482 | 483 | Research Development Engineer at University of Sydney. 2009 \~ 2010 484 | 485 | Education 486 | --------- 487 | 488 | PhD. Graph Visualization – University of Sydney. 2013 489 | 490 | Masters, Computer Programming – UNSW. 2009 491 | 492 | Software Engineering – University of Sydney. 2006 493 | 494 | Samuel Marks - Infrastructure Engineer 495 | ====================================== 496 | 497 | Bio 498 | --- 499 | 500 | Samuel has recently completed his PhD in Medicine at the University of 501 | Sydney where he focused on facilitating large-scale screening programmes 502 | through: Artificial Intelligence; biomedical engineering, eLearning and 503 | epidemiology. He expects to screen most of the world’s population in the 504 | next 5 years. To facilitate this — self-funded, patentless and 505 | open-source — endeavour, he runs an infrastructure and research focused 506 | software-engineering consultancy called [offscale.io](http://offscale.io/). 508 | 509 | Solving the world 1→∞ open-source projects at a time. PhD research 510 | attempts to solve glaucoma.Consultancy enables scalable engineering. 511 | 512 | Career 513 | ------ 514 | 515 | Director at Offscale.io. 2015 \~ present 516 | 517 | Senior Technology Specialist at Telstra. 2015 \~ 2015 518 | 519 | Senior Software Engineer at Alphatise. 2014 \~ 2014 520 | 521 | Inventor, Engineer, Founder at HealthPlatform.io. 2013 \~ 2014 522 | 523 | Engineering Lead at Abbrevi8. 2013 \~ 2014 524 | 525 | Software Engineer at Roamz. 2012 \~ 2012 526 | 527 | Researcher at Orion VM. 2012 \~ 2012 528 | 529 | Education 530 | --------- 531 | 532 | PhD, Medicine– University of Sydney. 2018 533 | 534 | Graduate Courseware, Computer Science – Harvard Extension School. 2015 535 | 536 | Science (B.Sc.) – Macquarie University.. 2014 537 | 538 | Publications 539 | ------------ 540 | 541 | Introduction to Python. 2012 542 | 543 | Maxim Zakharov - Golang Engineer 544 | ================================ 545 | 546 | Bio 547 | --- 548 | 549 | Maxim enjoys learning new algorithms and their variants, often 550 | challenging himself to devise modifications that improve upon their 551 | performance. He is curious about new technologies and new software tools 552 | that can improve his work. In his free time he contributes to open 553 | source projects and attends a number of meetups. 554 | 555 | Career 556 | ------ 557 | 558 | Contractor at Fujitsu Australia Software Technology. 2017 \~ present 559 | 560 | Senior Software Developer at Jesla Labs. 2015 \~ 2016 561 | 562 | Systems Engineer at Yatango. 2014 \~ 2015 563 | 564 | Applications Programmer at Muli Management Pty Ltd 2011 \~ 2013 565 | 566 | Education 567 | --------- 568 | 569 | Masters, Computer Science - M.V. Lomonosov Moscow State University. 1993 570 | 571 | Joseph Gentle - Golang Engineer 572 | =============================== 573 | 574 | Career 575 | ------ 576 | 577 | CTO at Prismatik. 2017 \~ present 578 | 579 | Senior Software Architect at hatch.team. 2017 \~ 2017 580 | 581 | Senior Software Engineer at Thinkmill. 2016 \~ 2016 582 | 583 | Senior Software Engineer at Level. 2013 \~ 2014 584 | 585 | Programming Teacher at Academy of Interactive Entertainment. 2012 \~ 586 | 2012 587 | 588 | Engineering Intern at Google. 2008 \~ 2008 589 | 590 | Research Assistant at UNSW. 2007 \~ 2008 591 | 592 | Education 593 | --------- 594 | 595 | 1st class Honors, Bachelor of Science (BSc) – University of New South 596 | Wales. 2007 597 | 598 | Fletcher Haynes - Golang Engineer 599 | ================================= 600 | 601 | Career 602 | ------ 603 | 604 | Lead Software Engineer at Unity Technologies. 2016 \~ 2018 605 | 606 | DevOps Engineer at Motiga. 2015 \~ 2016 607 | 608 | Systems Administrator at Willamette University. 2010 \~ 2015 609 | 610 | Education 611 | --------- 612 | 613 | Master’s Degree, Computer Science – Georgia Tech. 2017 614 | 615 | Md Samiul Alim Sakib - Golang Engineer 616 | ====================================== 617 | 618 | Bio 619 | --- 620 | 621 | Shakib is a Software Engineer from Dhaka, Bangladesh. He has extensive 622 | work experience on Mobile application development and developing backend 623 | service using different technology stacks like Java, Kotlin, Golang and 624 | Erlang. He has hands on experience developing Mobile messaging & 625 | Audio/Video calling application using XMPP, WebRTC. He has experience 626 | developing RESTful and gRPC based webservice utilising micro-service 627 | architecture and gathered experience working on highly distributed 628 | system. He has used PostgreSQL, MongoDB, ElasticSearch, Riak, Redis 629 | databases to store data. And RabbitMQ, EMQ, Kubernetes, Docker for 630 | DevOps. 631 | 632 | Career 633 | ------ 634 | 635 | Platform Engineer Pathao. 2017 \~ present 636 | 637 | Senior Software Engineer at NybSys. 2017 \~ 2017 638 | 639 | Software Engineer Bashundhara Group. 2016 \~ 2017 640 | 641 | Android Trainer at Google Developers Group. 2015 \~ 2015 642 | 643 | Education 644 | --------- 645 | 646 | B.Sc.– United International University. 2016 647 | 648 | Zhiyi Wei - Golang Engineer 649 | =========================== 650 | 651 | Bio 652 | --- 653 | 654 | Zhiyi has 10+ years experience in 655 | 1.Software full stack developments 656 | 2.iOS and Android app developments 657 | 3.System Network security 658 | 4.Software reverse engineering 659 | 5.Focus on high performance and low latency 660 | 661 | Recent projects: 662 | Created Skywire for Skycoin, which is a skycoin miner that let users 663 | earn coins by sharing their bandwidth to others 664 | Created an IoT platform 665 | Created an Chinese mobile game 666 | Created automatic stock trading terminal application through software 667 | reverse engineering 668 | 669 | Career 670 | ------ 671 | 672 | Senior Software Engineer at Guangdong Vanward New Electric Co., Ltd.. 673 | 2014 \~ 2016 674 | 675 | Senior Software Engineer at Guangzhou QingTianZhu Network Technology 676 | Co., Ltd. 2013 \~ 2014 677 | 678 | Software Engineer at Shenzhen Coship electronics Limited by Share Ltd. 679 | 2011 \~ 2013 680 | 681 | Education 682 | --------- 683 | 684 | PhD– Tsinghua University. 2011 685 | 686 | Bastian Wieck - Golang Engineer 687 | =============================== 688 | 689 | Bio 690 | --- 691 | 692 | Bastian is a Golang and Java Full-Stack Developer. His experience 693 | includes projects for Desktop, Web and Android Applications. His code is 694 | clean and efficient. He only provides high-quality service. 695 | 696 | Go, Python, C\# and Java Developer, shaping the future one byte at the time 697 | --------------------------------------------------------------------------- 698 | 699 | Career 700 | ------ 701 | 702 | Lead Teaching Assistant for Computer Science at Georgia Southern 703 | University. 2015 \~ 2017 704 | 705 | Business Intelligence Analyst at The Coca-Cola Company. 2017 \~ 2017 706 | 707 | Google Summer of Code participant with CERN. 2017 \~ 2017 708 | 709 | Education 710 | --------- 711 | 712 | BS, Computer Science - Georgia Southern University. 2017 713 | 714 | Roan Brand - Golang Engineer 715 | ============================ 716 | 717 | Career 718 | ------ 719 | 720 | Intermediate Software Developer at IMQS Software. 2015 \~ present 721 | 722 | Embedded System Developer at F&B Electrical. 2011 \~ 2015 723 | 724 | Education 725 | --------- 726 | 727 | Electrical and Electronics Engineering– University of Stellenbosch. 2014 728 | 729 | Brian Acton - Golang Engineer 730 | ============================= 731 | 732 | Bio 733 | --- 734 | 735 | Experienced Developer with a demonstrated history of working in the 736 | financial services industry. Skilled in Business Process, Operations 737 | Management, Analytical Skills, Databases, and Team Building. Strong 738 | engineering professional. 739 | 740 | Career 741 | ------ 742 | 743 | Senior Developer at InTarget Mobile Advertising. 2018\~ present 744 | 745 | Solutions Analyst at P:Cubed. 2013 \~ 2018 746 | 747 | Consultant at BIXIT. 2011 \~ 2012 748 | 749 | CEO at Titan. 2006 \~ 2009 750 | 751 | PSO, 2ic at Erinys Iraq. 2004 \~ 2006 752 | 753 | Consultant at Dato Solutions. 2002 \~ 2002 754 | 755 | Consultant at Paracon. 1998 \~ 2000 756 | 757 | COBOL Programmer at SCMB. 1995 \~ 1997 758 | 759 | Peter Badenhorst - Golang Engineer 760 | ================================== 761 | 762 | Career 763 | ------ 764 | 765 | Software Developer at VMG Software. 2014 \~ Present 766 | 767 | Developer at Quantum Health Services. 2012 \~ 2013 768 | 769 | Software Developer at GreatGuide. 2005 \~ 2011 770 | 771 | Jong Chul Park - Middleware Java Engineer 772 | ========================================= 773 | 774 | Career 775 | ------ 776 | 777 | Founder and the CEO of MIRincom. 2005\~ present 778 | 779 | CTO of Uracle 2001\~ 2005 780 | 781 | Senior Researcher at Hyundai Electronic. 1996 \~ 2001 782 | 783 | Education 784 | --------- 785 | 786 | Masters, Computer Science – Kyung Hee University. 1996 787 | 788 | Publications 789 | ------------ 790 | 791 | A Study on the Multi-Network survival Map Using Smoothing Algorithm 1995 792 | 793 | Email System Using the Korean Mmenu on UNIX 1994 794 | 795 | Kang Ho Kim - Middleware Java Engineer 796 | ====================================== 797 | 798 | Career 799 | ------ 800 | 801 | CTO of MIRincom. 2007\~ present 802 | 803 | Project Manager at KTI. 2001\~ 2007 804 | 805 | Senior Researcher at Taeha Mechatronics Co. 1998 \~ 2001 806 | 807 | Education 808 | --------- 809 | 810 | Masters, Biomedical Engineering – Hanyang Univ. 1998 811 | 812 | Jung Hwa Ye - Middleware Java Engineer 813 | ====================================== 814 | 815 | Career 816 | ------ 817 | 818 | CTO of MIRincom. 2006\~ present 819 | 820 | General Manager at Uracle. 2001\~ 2006 821 | 822 | Senior Researcher at Hyundai Electronic. 1995 \~ 2001 823 | 824 | Education 825 | --------- 826 | 827 | Electronic Engineering – Kangwon National University. 1996 828 | 829 | Chan Yeul Jo - Middleware Java Engineer 830 | ======================================= 831 | 832 | Career 833 | ------ 834 | 835 | CTO of MIRincom. 2006\~ present 836 | 837 | General Manager at Uracle. 2001\~ 2006 838 | 839 | Senior Researcher at Hyundai Electronic. 1995 \~ 2001 840 | 841 | Education 842 | --------- 843 | 844 | Electronic Engineering – Kangwon National University. 1996 845 | -------------------------------------------------------------------------------- /distributed.md: -------------------------------------------------------------------------------- 1 | **Fantom:** 2 | 3 | **Distributed Computing** 4 | 5 | **[Introduction](#introduction) 2** 6 | 7 | **[Background](#background) 2** 8 | 9 | > [Price of Computing](#price-of-computing) 2 10 | > 11 | > [Compute vs Storage](#compute-vs-storage) 3 12 | > 13 | > [Compute Architecture](#compute-architecture) 3 14 | > 15 | > [Tightly Coupled Architecture](#tightly-coupled-architecture) 3 16 | 17 | **[Redesigning Stateless Computing](#redesigning-stateless-computing) 18 | 3** 19 | 20 | **[Time Complexity](#time-complexity) 4** 21 | 22 | **[Job Scheduling](#job-scheduling) 4** 23 | 24 | **[Verifiable Computing](#verifiable-computing) 5** 25 | 26 | **[Deterministic Verifiable 27 | Computing](#deterministic-verifiable-computing) 9** 28 | 29 | **[Decoupling Cost](#section-1) 9** 30 | 31 | **[Job Scheduling Conflicts](#job-scheduling-conflicts) 10** 32 | 33 | **[Job Scheduling](#job-scheduling-1) 10** 34 | 35 | > [Job Propagation k/n](#job-propagation-kn) 10 36 | > 37 | > [Job Propagation Leader Selection](#job-propagation-leader-selection) 38 | > 11 39 | > 40 | > [Job Propagation Cryptographic 41 | > Sortition](#job-propagation-cryptographic-sortition) 11 42 | 43 | **[Deterministic Verifiable Job Propagation Compute 44 | Marketplace](#section-2) 11** 45 | 46 | **[Conclusion](#conclusion) 12** 47 | 48 | 49 | = 50 | 51 | Introduction 52 | ============ 53 | 54 | Distributed Computing in a decentralized context is currently only as 55 | efficient as the consensus winning node. The goal is to have the 56 | combined computing power of all participants. Instead we have the 57 | computing power of a single node. We propose a cheap, asynchronous, 58 | fault tolerant, verifiable alternative to current decentralized 59 | solutions. 60 | 61 | Background 62 | ========== 63 | 64 | Price of Computing 65 | ------------------ 66 | 67 | The current computing standard is cloud computing services. AWS, Google, 68 | Azure. We will consider AWS as our benchmark. 69 | 70 | t2.medium on-demand: $0.0464 per Hour 71 | 72 | t2.medium spot-pricing: $0.026 per Hour 73 | 74 | t2.medium reserved instance: $0.027 per Hour 75 | 76 | Lambda: $0.20 per 1 million requests, $0.00001667 per GB-second of 77 | compute 78 | 79 | Aurora(RDS): $0.1 per GB-month, $0.2 per 1 million requests 80 | 81 | Cost Example 82 | 83 | Low-traffic Account CRUD API (Lambda) 84 | 85 | \~400,000 requests per month 86 | 87 | $0.25/mo (@200ms per request) 88 | 89 | Low-traffic Account CRUD API (Aurora - RDS) 90 | 91 | \~400,000 requests per month 92 | 93 | $0.3/mo 94 | 95 | Comparing an Ethereum Solution 96 | 97 | Low-traffic Account CRUD API (Ethereum) 98 | 99 | \~400,000 requests per month (Average between inserts, updates, and 100 | balance requests) 101 | 102 | 3.3 billion gas @ 50 gwei = 168 ETH = $68,208.00 103 | 104 | Cost differential 105 | 106 | The principal of a world computer is to be able to leverage all of the 107 | computing capacity of all participating nodes. Given the Proof-of-Work 108 | consensus design, only a single block can be created every epoch. All 109 | nodes must execute the same block to arrive at the same state. Thus, 110 | instead of having the cumulative computing power of all nodes, we have 111 | the computing power of a single node. 112 | 113 | Compute vs Storage 114 | ------------------ 115 | 116 | AWS S3: $0.023 / GB 117 | 118 | AWS Glacier $0.004 / GB 119 | 120 | There is no linear correlation between compute capacity, and storage 121 | capacity. Storage and Computing can not be tightly coupled in a 122 | decentralized environment. 123 | 124 | Compute Architecture 125 | -------------------- 126 | 127 | - CPU/GPU perform stateless computing. 128 | 129 | - Memory allows for temporary fast access storage. 130 | 131 | - Disk allows for permanent\* slow access storage. 132 | 133 | Compute architecture leverages off-of the above 3 principals. Fast 134 | computing loads from slow storage what it needs into fast access memory 135 | to allow for computing to manipulate fast access memory and then write 136 | back to slow storage. 137 | 138 | Tightly Coupled Architecture 139 | ---------------------------- 140 | 141 | Storage and Compute in Ethereum VM are tightly coupled. They are 142 | inherent in the OPcodes of the virtual machine. 143 | 144 | With no correlation between Computing and Storage, and no correlation in 145 | Compute Architecture, this tight coupling must be removed to be 146 | feasible. 147 | 148 | Redesigning Stateless Computing 149 | =============================== 150 | 151 | Network of *n* participants. 152 | 153 | Data source of *ds*. 154 | 155 | Execution set of *c*. 156 | 157 | *1/n* compute nodes executes *c* with inputs *ds*. 158 | 159 | Compute Node Risk 160 | 161 | 1. Infinite execution time. 162 | 163 | 2. Out of memory. 164 | 165 | Compute Provider Risk 166 | 167 | 1. Node terminates before execution finishes. 168 | 169 | 2. Inaccurate execution results. 170 | 171 | Problem Statement \#1 172 | 173 | The compute node must be able to assess the compute requirements of the 174 | computation. 175 | 176 | Problem Statement \#2 177 | 178 | The compute node must be able to assess the memory requirements of the 179 | computation. 180 | 181 | Problem Statement \#3 182 | 183 | The compute provider must be able to have confirmation of execution 184 | results. 185 | 186 | Problem Statement \#4 187 | 188 | The compute provider must be able to confirm the validity of the 189 | resulting output. 190 | 191 | Time Complexity 192 | =============== 193 | 194 | Constant O(1) 195 | 196 | Logarithmic O(log n) 197 | 198 | Polylogarithmic O((log n)k) 199 | 200 | Sub-linear o(n) or O(n1/2) 201 | 202 | Linear O(n) 203 | 204 | Quasilinear O(n logk n) 205 | 206 | Sub-quadratic o(n2) 207 | 208 | Polynomial O(nk) 209 | 210 | Key qualities of a compute job would need to include 211 | 212 | - Determinism 213 | 214 | - Precise computational steps 215 | 216 | The Ethereum Virtual Machine established this by linking Gas costs to 217 | each OPcode execution. Thus calculating execution time\* and memory 218 | requirements\* for a given set of inputs. This cost is tightly coupled 219 | with execution. 220 | 221 | A compute node can given a set of inputs (data source) and set of 222 | instructions be able to assess the execution and memory requirements of 223 | the specific job. 224 | 225 | Job Scheduling 226 | ============== 227 | 228 | Related works in centralized scheduling 229 | 230 | Cloud task and virtual machine allocation strategy[1] 231 | 232 | - Total execution time of all tasks 233 | 234 | Optimal scheduling of computational tasks[2] 235 | 236 | - Execution time - Virtual Machine Tree 237 | 238 | A deadline scheduler for jobs[3] 239 | 240 | - Execution time and cost - Cloud Least Laxity First 241 | 242 | Job scheduling algorithm based on Berger[4] 243 | 244 | - Execution time 245 | 246 | Online optimization for scheduling preemptable tasks on Iaas cloud 247 | systems[5] 248 | 249 | - Computational power, execution time, bandwidth - Dynamic allocation 250 | 251 | A priority based job scheduling algorithm[6] 252 | 253 | Performance and cost evaluation of Gang Scheduling in a Cloud Computing 254 | system with job migrations and starvation handling[7] 255 | 256 | - Response time and bounded slowdown 257 | 258 | Given *n* nodes we can make the following assumptions. 259 | 260 | - Optimized efficiency has exactly *1/n* nodes execute the given 261 | > compute task. 262 | 263 | - Fault tolerance has at least *3/n* nodes execute the given compute 264 | > task. 265 | 266 | - Multi Party Computing (MPC) for verifiable results has at least 3/n 267 | > nodes execute the given compute task. 268 | 269 | Given that MPC requires *3/n* and fault tolerance requires *3/n*, we 270 | require *9/n* for fault tolerant multi party computation. This is an 271 | optimized strategy. 272 | 273 | Verifiable Computing 274 | ==================== 275 | 276 | Related works in Interactive Proofs 277 | 278 | Verifiable Computation with Massively Parallel Interactive Proofs[8] 279 | 280 | - GPU parallel processing for arithmetic circuits of polylogarithmic 281 | > depth 282 | 283 | - No privacy 284 | 285 | - Publicly Verifiable 286 | 287 | - Efficient 288 | 289 | - Circuits of polylogarithmic depth 290 | 291 | Allspice: A Hybrid Architecture for Interactive Verifiable 292 | Computation[9] 293 | 294 | - Verify computations expressed as straight-line programs. 295 | 296 | - No privacy 297 | 298 | - Publicly Verifiable 299 | 300 | - Amortized Efficiency 301 | 302 | - Arithmetic Circuits 303 | 304 | Pepper: Making Argument Systems for Outsourced Computation Practical 305 | (Sometimes)[10] 306 | 307 | - Arithmetic constraints instead of circuits, very limited class of 308 | > functions 309 | 310 | - No privacy 311 | 312 | - Not Publicly Verifiable 313 | 314 | - Amortized Efficiency 315 | 316 | - Arithmetic Circuits 317 | 318 | Ginger: Taking Proof-Based Verified Computation a Few Steps Closer to 319 | Practicality[11] 320 | 321 | - Improvement on Pepper, larger class of computations 322 | 323 | - No privacy 324 | 325 | - Not Publicly Verifiable 326 | 327 | - Amortized Efficiency 328 | 329 | - Arithmetic Circuits 330 | 331 | Zataar: Resolving the Conflict Between Generality and Plausibility in 332 | Verified Computation[12] 333 | 334 | - PCP using algebraic representations as Quadratic Arithmetic Programs 335 | 336 | - No privacy 337 | 338 | - Not Publicly Verifiable 339 | 340 | - Amortized Efficiency 341 | 342 | - Arithmetic Circuits 343 | 344 | Pantry: Verifying Computations with State[13] 345 | 346 | - Zataar improvement which allows verification of stateful 347 | > computations 348 | 349 | - No privacy 350 | 351 | - Not Publicly Verifiable 352 | 353 | - Amortized Efficiency 354 | 355 | - Stateful 356 | 357 | River: Verifiable Computation with Reduced Informational Costs and 358 | Computational Costs[14] 359 | 360 | - Quadratic Arithmetic Program based verifiable computing system. 361 | 362 | - No privacy 363 | 364 | - Publicly Verifiable 365 | 366 | - Amortized Efficiency 367 | 368 | - Arithmetic Circuits 369 | 370 | Buffet: Efficient RAM and control flow in verifiable outsourced 371 | computation[15] 372 | 373 | - Support for general loops 374 | 375 | Related works in Non-Interactive Proofs 376 | 377 | Pinocchio: Nearly Practical Verifiable Computation[16] 378 | 379 | - Arithmetic circuits, no input-output privacy 380 | 381 | Gepetto: Versatile Verifiable Computation[17] 382 | 383 | - Public verifiability, no input-output privacy. 384 | 385 | - No Privacy 386 | 387 | - Publicly Verifiable 388 | 389 | - Amortized Efficiency 390 | 391 | - General Loops 392 | 393 | SNARKs for C: Verifying Program Executions Succinctly and in Zero 394 | Knowledge[18] 395 | 396 | - Increased overhead. Based on Quadratic Arithmetic Programs. Public 397 | > verifiability without input-output privacy. 398 | 399 | - No Privacy 400 | 401 | - Publicly Verifiable 402 | 403 | - Amortized Efficiency 404 | 405 | - General Loops 406 | 407 | Succinct Non-Interactive Zero Knowledge for a von Neumann 408 | Architecture[19] 409 | 410 | - Quadratic Arithmetic Program based SNARK with more efficient 411 | > verification and proof generation. Universal circuit generator. 412 | 413 | - No Privacy 414 | 415 | - Publicly Verifiable 416 | 417 | - Amortized Efficiency 418 | 419 | - General Loops 420 | 421 | ADSNARK: Nearly Practical and Privacy-Preserving Proofs on Authenticated 422 | Data[20] 423 | 424 | - Straight-line computations on authenticated data. Publicly 425 | > verifiable and more efficient privately verifiable proof 426 | 427 | - Input Only Privacy 428 | 429 | - Publicly Verifiable 430 | 431 | - Amortized Efficiency 432 | 433 | - Arithmetic Circuits 434 | 435 | Block Programs: Improving Efficiency of Verifiable Computation for 436 | Circuits with Repeated Substructures[21] 437 | 438 | - More efficient way to handle loops in a program 439 | 440 | Related works in Fully Homomorphic Encryption 441 | 442 | Non-Interactive Verifiable Computing: Outsourcing Computation to 443 | Untrusted Workers[22] 444 | 445 | - Yao’s garbled circuits with Fully Homomorphic Encryption, privacy 446 | > preserving 447 | 448 | - Input & Output Privacy 449 | 450 | - Not Publicly Verifiable 451 | 452 | - Amortized Efficiency 453 | 454 | - Arithmetic Circuits 455 | 456 | Improved Delegation of Computation Using Fully Homomorphic 457 | Encryption[23] 458 | 459 | - Input & Output Privacy 460 | 461 | - Not Publicly Verifiable 462 | 463 | - Amortized Efficiency 464 | 465 | - Arithmetic Circuits 466 | 467 | Related works based on Message Authentication Codes 468 | 469 | Verifiable Delegation of Computation on Outsourced Data[24] 470 | 471 | - Bilinear maps and closed-form efficiency. Preprocessing stage. 472 | 473 | - No Privacy 474 | 475 | - Not Publicly Verifiable 476 | 477 | - Amortized Efficiency 478 | 479 | - Polynomial of Degree 2 480 | 481 | Generalized Homomorphic macs with Efficient Verification[25] 482 | 483 | - *ζ*-linear maps, supports arithmetic circuits of depth *ζ* 484 | 485 | Efficiently Verifiable Computation on Encrypted Data[26] 486 | 487 | - Multivariate polynomials of degree 2 with input privacy 488 | 489 | - Input Privacy 490 | 491 | - Not Publicly Verifiable 492 | 493 | - Amortized Efficiency 494 | 495 | - Polynomial of Degree 2 496 | 497 | A number of strategies exist for verifiable computing. 498 | 499 | - Interactive Knowledge Proofs 500 | 501 | - Interactive 502 | 503 | - Variable attestation 504 | 505 | - Computation Overhead 506 | 507 | - Example: Buffet 508 | 509 | - Non-Interactive Knowledge Proofs 510 | 511 | - Trusted Setup\* 512 | 513 | - Fixed attestation 514 | 515 | - Computational Overhead 516 | 517 | - Example: ADSNARK, zkSNARK 518 | 519 | - Trusted Execution Environments (TEE) 520 | 521 | - Hardware Requirement 522 | 523 | - Centralization 524 | 525 | - High Security 526 | 527 | - Fast Execution 528 | 529 | - Example: TPM, TXT, Intel SGX, ARM TrustZone 530 | 531 | - Multi Party Computation (MPC) 532 | 533 | - Multiple Participants 534 | 535 | - Unequal reward structures 536 | 537 | - Example: Ethereum 538 | 539 | Viable Options include 540 | 541 | - zk-SNARK wrapped Virtual Machine (Execution overhead, low barrier to 542 | > entry) 543 | 544 | - TEE wrapped Virtual Machine (Execution optimized, high barrier to 545 | > entry) 546 | 547 | - MPC with Probabilistic Payments (Execution inefficient, low barrier 548 | > to entry) 549 | 550 | Deterministic Verifiable Computing 551 | ================================== 552 | 553 | Given; 554 | 555 | - Fixed cost Opcodes 556 | 557 | - Verifiable Computing 558 | 559 | - Multi node fault tolerance redundancy 560 | 561 | We can accomplish; 562 | 563 | - Fixed length execution assessment 564 | 565 | - Compute cost execution assessment 566 | 567 | - Verifiable Computing Results 568 | 569 | - Fault Tolerance 570 | 571 | Decoupling Cost 572 | =============== 573 | 574 | A fee based token economy marketplace will be required to ensure fair 575 | value. 576 | 577 | Tasks are associated with a bid: the amount of coin offered for 578 | performing the task. Bidders can adjust the bid on their pending tasks 579 | to expedite their execution. Workers will decide if a bid is sufficient 580 | for them to execute upon. Workers will execute work when profitable for 581 | them to do so. 582 | 583 | A compute node can decide to execute a given job for less than the 584 | expected fee payment. A compute provider can provide a fee less than the 585 | indicated execution cost. 586 | 587 | Job Scheduling Conflicts 588 | ======================== 589 | 590 | Given 591 | 592 | - *n* nodes 593 | 594 | - *k* as our fault tolerance variable 595 | 596 | We want *k/n* to execute a given job with the following criteria 597 | 598 | - *k* is willing to accept the job based on the OPcode cost 599 | 600 | - *k* is willing to accept the job based on the execution fee proposed 601 | 602 | Risk 603 | 604 | - No nodes willing to accept the job (No profitability attack) 605 | 606 | - *< k* nodes are willing to accept the job 607 | 608 | - All nodes are willing to accept the job (Too profitable attack) 609 | 610 | Job scheduling with a scheduler is a fairly well established field of 611 | study. In a decentralized environment, we lack a scheduler. 612 | 613 | Job Scheduling 614 | =============== 615 | 616 | To achieve decentralized job scheduling we discuss the following 617 | strategies 618 | 619 | - *k/n* selection with a first come leader selection 620 | 621 | - Stake based leader selection 622 | 623 | - Cryptographic Sortition participant selection 624 | 625 | Job Propagation k/n 626 | ------------------- 627 | 628 | Job requests are unique. Each node holds a list of all job IDs they have 629 | received. 630 | 631 | Each node that receives a request attempts to act as a job scheduler. 632 | 633 | Upon receiving a compute request with an empty job order the compute 634 | node *n1* confirms if they are willing to accept the job. If 635 | they are, they sign the request, randomly select *k* nodes, adds each to 636 | the job order and propagates to each node. 637 | 638 | Each node receiving the request can accept or deny the request. If they 639 | accept, they sign and propagate to the listed job order nodes. If *y* 640 | nodes have accepted, but *k* has not been reached, *n1* 641 | elects *k-y* new nodes and continues this cycle. If 642 | *n1\ *knows < *k* nodes *t* it sends the job to *t* nodes 643 | and elects one of *t* nodes as the new leader. 644 | 645 | Job Schedulers are allowed to collect the fees. 646 | 647 | - Risk of less than *k* nodes known 648 | 649 | - Denial attacks by *n1* 650 | 651 | - Centralized towards *n1* 652 | 653 | - Long potential job acceptance time 654 | 655 | Job Propagation Leader Selection 656 | -------------------------------- 657 | 658 | Compute nodes stake tokens for leader election. Each epoch a leader 659 | *nl* is elected to be the job scheduler. The elected leader 660 | sends out the job request signed with it as leader. Receiving nodes can 661 | validate that *nl\ *is the correct leader for the epoch. If a 662 | node is willing to accept the job they sign the request and send back to 663 | the leader. The leader can then choose a subset of nodes to execute the 664 | given job. 665 | 666 | Further optimization: Job scheduling based on cryptographic proofs of 667 | resources available\* 668 | 669 | Job Schedulers are allowed to collect the fees. 670 | 671 | - Risk of malicious *nl* 672 | 673 | - Denial attacks by *nl* 674 | 675 | - Fast job acceptance time 676 | 677 | - Further scheduling optimization possible 678 | 679 | Job Propagation Cryptographic Sortition 680 | --------------------------------------- 681 | 682 | Compute nodes each have an algorithmic lottery chance. The job ID is 683 | used as the seed for the Cryptographic Sortition, all nodes willing to 684 | participate, participate in the sortition. Nodes with a winning match 685 | are allowed to participate. 686 | 687 | The highest hash seed matching the winning ticket is awarded the fees if 688 | they complete the job. 689 | 690 | - More than *k* participants 691 | 692 | Deterministic Verifiable Job Propagation Compute Marketplace 693 | ============================================================ 694 | 695 | Given; 696 | 697 | - Fixed cost Opcodes 698 | 699 | - Verifiable Computing 700 | 701 | - Multi node fault tolerance redundancy 702 | 703 | - Job Propagation 704 | 705 | - Fee decoupling 706 | 707 | We can accomplish; 708 | 709 | - Fixed length execution assessment 710 | 711 | - Compute cost execution assessment 712 | 713 | - Verifiable Computing Results 714 | 715 | - Fault Tolerance 716 | 717 | - k/n selection for efficient computing 718 | 719 | - Cost efficient marketplace 720 | 721 | Conclusion 722 | ========== 723 | 724 | A deterministic, verifiable, market value driven, fault tolerant, 725 | asynchronous world compute engine. We allow for multiple verifiable 726 | compute strategies as well as multiple job selection strategies. The 727 | proposal allows for a compute environment that gravitates towards a 728 | market value compute requirement with low cost resources available for 729 | the ecosystem. 730 | 731 | [1] Xu, X., Hu, H., Hu, N., Ying, W.: Cloud task and virtual machine 732 | allocation strategy in cloud computing environment. In: Lei, J., Wang, 733 | F.L., Li, M., Luo, Y. (eds.) NCIS 2012. CCIS, vol. 345, pp. 113–120. 734 | Springer, Heidelberg (2012) 735 | 736 | [2] Achar, R., Thilagam, P.S., Shwetha, D., et al.: Optimal scheduling 737 | of computational task in cloud using virtual machine tree. In: 2012 738 | Third International Conference on Emerging Applications of Information 739 | Technology (EAIT), pp. 143–146 (2012) 740 | 741 | [3] Perret, Q., Charlemagne, G., Sotiriadis, S., Bessis, N.: A deadline 742 | scheduler for jobs in distributed systems. In: 2013 27th International 743 | Conference on Advanced Information Networking and Applications Workshops 744 | (WAINA), pp. 757–764 (2013) 745 | 746 | [4] Baomin, X., Zhao, C., Enzhao, H., Bin, H.: Job scheduling algorithm 747 | based on Berger model in cloud environment. Adv. Eng. Softw. 42, 419–425 748 | (2011) 749 | 750 | [5] Li, J., Qiu, M., Ming, Z., Quan, G., Qin, X., Gu, Z.: Online 751 | optimization for scheduling preemptable tasks on IaaS cloud systems. J. 752 | Parallel Distrib. Comput. 72(5), 666–677 (2012) 753 | 754 | [6] Ghanbaria, S., Othmana, M.: A priority based job scheduling 755 | algorithm in cloud computing. In: ICASCE 2012, pp. 778–785 (2012) 756 | 757 | [7] Moschakis, I.A., Karatza, H.D.: Performance and cost evaluation of 758 | Gang Scheduling in a Cloud Computing system with job migrations and 759 | starvation handling. In: IEEE Symposium on Computers and Communications 760 | (ISCC) (2012) and 2011 IEEE Symposium on Computers and Communications, 761 | pp. 418–423 (2011) 762 | 763 | [8] Justin Thaler, Mike Roberts, Michael Mitzenmacher, and Hanspeter 764 | Pfister. Verifiable computation with massively parallel interactive 765 | proofs. In 4th USENIX Workshop on Hot Topics in Cloud Computing, 766 | HotCloud’12, Boston, MA, USA, June 12-13, 2012, 2012. 767 | 768 | [9] Victor Vu, Srinath T. V. Setty, Andrew J. Blumberg, and Michael 769 | Walfish. A hybrid architecture for interactive verifiable computation. 770 | In 2013 IEEE Symposium on Security and Privacy, SP 2013, Berkeley, CA, 771 | USA, May 19-22, 2013, pages 223– 237, 2013. 772 | 773 | [10] Srinath T. V. Setty, Richard McPherson, Andrew J. Blumberg, and 774 | Michael Walfish. Making argument systems for outsourced computation 775 | practical (sometimes). In 19th Annual Network and Distributed System 776 | Security Symposium, NDSS 2012, San Diego, California, USA, February 5-8, 777 | 2012, 2012. 778 | 779 | [11] Srinath T. V. Setty, Victor Vu, Nikhil Panpalia, Benjamin Braun, 780 | Andrew J. Blumberg, and Michael Walfish. Taking proof-based verified 781 | computation a few steps closer to practicality. In Proceedings of the 782 | 21th USENIX Security Symposium, Bellevue, WA, USA, August 8-10, 2012, 783 | pages 253–268, 2012. 784 | 785 | [12] Srinath T. V. Setty, Benjamin Braun, Victor Vu, Andrew J. Blumberg, 786 | Bryan Parno, and Michael Walfish. Resolving the conflict between 787 | generality and plausibility in verified computation. In Eighth Eurosys 788 | Conference 2013, EuroSys ’13, Prague, Czech Republic, April 14-17, 2013, 789 | pages 71–84, 2013. 790 | 791 | [13] Benjamin Braun, Ariel J. Feldman, Zuocheng Ren, Srinath T. V. 792 | Setty, Andrew J. Blumberg, and Michael Walfish. Verifying computations 793 | with state. In ACM SIGOPS 24th Symposium on Operating Systems 794 | Principles, SOSP ’13, Farmington, PA, USA, November 3-6, 2013, pages 795 | 341–357, 2013. 796 | 797 | [14] Gang Xu, George T. Amariucai, and Yong Guan. Verifiable computation 798 | with reduced informational costs and computational costs. In Computer 799 | Security - ESORICS 2014 - 19th European Symposium on Research in 800 | Computer Security, Wroclaw, Poland, September 7-11, 2014. Proceedings, 801 | Part I, pages 292–309, 2014. 802 | 803 | [15] Riad S. Wahby, Srinath T. V. Setty, Zuocheng Ren, Andrew J. 804 | Blumberg, and Michael Walfish. Efficient RAM and control flow in 805 | verifiable outsourced computation. In 22nd Annual Network and 806 | Distributed System Security Symposium, NDSS 2015, San Diego, California, 807 | USA, February 8-11, 2014, 2015. 808 | 809 | [16] Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. 810 | Pinocchio: Nearly practical verifiable computation. In 2013 IEEE 811 | Symposium on Security and Privacy, SP 2013, Berkeley, CA, USA, May 812 | 19-22, 2013, pages 238–252, 2013. 813 | 814 | [17] Craig Costello, C´edric Fournet, Jon Howell, Markulf Kohlweiss, 815 | Benjamin Kreuter, Michael Naehrig, Bryan Parno, and Samee Zahur. 816 | Geppetto: Versatile verifiable computation. In 2015 IEEE Symposium on 817 | Security and Privacy, SP 2015, San Jose, CA, USA, May 17-21, 2015, pages 818 | 253–270, 2015. 819 | 820 | [18] Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran Tromer, and 821 | Madars Virza. Snarks for C: verifying program executions succinctly and 822 | in zero knowledge. In Advances in Cryptology - CRYPTO 2013 - 33rd Annual 823 | Cryptology Conference, Santa Barbara, CA, USA, August 18-22, 2013. 824 | Proceedings, Part II, pages 90–108, 2013. 825 | 826 | [19] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. 827 | Succinct noninteractive zero knowledge for a von neumann architecture. 828 | In Proceedings of the 23rd USENIX Security Symposium, San Diego, CA, 829 | USA, August 20-22, 2014., pages 781–796, 2014. 830 | 831 | [20] Michael Backes, Manuel Barbosa, Dario Fiore, and Raphael M. 832 | Reischuk. ADSNARK: nearly practical and privacy-preserving proofs on 833 | authenticated data. In 2015 IEEE Symposium on Security and Privacy, SP 834 | 2015, San Jose, CA, USA, May 17-21, 2015, pages 271–286, 2015. 835 | 836 | [21] Gang Xu, George T. Amariucai, and Yong Guan. Block programs: 837 | Improving efficiency of verifiable computation for circuits with 838 | repeated substructures. In Proceedings of the 10th ACM Symposium on 839 | Information, Computer and Communications Security, ASIA CCS ’15, 840 | Singapore, April 14-17, 2015, pages 405–416, 2015. 841 | 842 | [22] Rosario Gennaro, Craig Gentry, and Bryan Parno. Non-interactive 843 | verifiable computing: Outsourcing computation to untrusted workers. In 844 | Advances in Cryptology - CRYPTO 2010, 30th Annual Cryptology Conference, 845 | Santa Barbara, CA, USA, August 15-19, 2010. Proceedings, pages 465–482, 846 | 2010. 847 | 848 | [23] Kai-Min Chung, Yael Tauman Kalai, and Salil P. Vadhan. Improved 849 | delegation of computation using fully homomorphic encryption. In 850 | Advances in Cryptology - CRYPTO 2010, 30th Annual Cryptology Conference, 851 | Santa Barbara, CA, USA, August 15-19, 2010. Proceedings, pages 483–501, 852 | 2010. 853 | 854 | [24] Michael Backes, Dario Fiore, and Raphael M. Reischuk. Verifiable 855 | delegation of computation on outsourced data. In 2013 ACM SIGSAC 856 | Conference on Computer and Communications Security, CCS’13, Berlin, 857 | Germany, November 4-8, 2013, pages 863–874, 2013. 858 | 859 | [25] Liang Feng Zhang and Reihaneh Safavi-Naini. Generalized homomorphic 860 | macs with efficient verification. In ASIAPKC’14, Proceedings of the 2nd 861 | ACM Wookshop on ASIA Public-Key Cryptography, June 3, 2014, Kyoto, 862 | Japan, pages 3–12, 2014. 863 | 864 | [26] Dario Fiore, Rosario Gennaro, and Valerio Pastro. Efficiently 865 | verifiable computation on encrypted data. In Proceedings of the 2014 ACM 866 | SIGSAC Conference on Computer and Communications Security, Scottsdale, 867 | AZ, USA, November 3-7, 2014, pages 844–855, 2014. 868 | -------------------------------------------------------------------------------- /vm.md: -------------------------------------------------------------------------------- 1 | **Fantom:** 2 | 3 | **Virtual Machine** 4 | 5 | **[Introduction](#introduction) 3** 6 | 7 | **[Background](#background) 3** 8 | 9 | > [Register Based VM](#register-based-vm) 3 10 | > 11 | > [Stack-Based Model](#stack-based-model) 3 12 | > 13 | > [Register-Based Model](#register-based-model) 4 14 | 15 | **[Virtual Machine](#virtual-machine) 5** 16 | 17 | > [Secure, Powerful VM with 18 | > Turing-completeness](#secure-powerful-vm-with-turing-completeness) 5 19 | > 20 | > [Smart Contract Language](#smart-contract-language) 5 21 | > 22 | > [Scala Based Compiler](#scala-based-compiler) 6 23 | > 24 | > [Smart Contract Production Tools](#smart-contract-production-tools) 7 25 | > 26 | > [Smart Contract Protocol](#smart-contract-protocol) 8 27 | 28 | **[Applications](#applications) 9** 29 | 30 | > [Example Application: Food 31 | > Delivery](#example-application-food-delivery) 9 32 | 33 | **[Research](#research) 11** 34 | 35 | > [Background](#background-1) 11 36 | > 37 | > [Architectural Overview](#architectural-overview) 11 38 | > 39 | > [Trustless Verifiable Computing](#trustless-verifiable-computing) 11 40 | > 41 | > [Trustless VM](#trustless-vm) 13 42 | > 43 | > [Stateless Computing](#stateless-computing) 14 44 | > 45 | > [Achieving Fast Attestations](#achieving-fast-attestations) 15 46 | > 47 | > [Execution Trust](#execution-trust) 16 48 | > 49 | > [Decoupling Token Value](#decoupling-token-value) 16 50 | > 51 | > [Pledge Penalty](#pledge-penalty) 16 52 | > 53 | > [Contract Life Cycle](#contract-life-cycle) 17 54 | > 55 | > [Privacy Preserving](#privacy-preserving) 17 56 | 57 | **[Additional Improvements](#additional-improvements) 19** 58 | 59 | > [FastVM](#fastvm) 19 60 | > 61 | > [Solidity++](#solidity) 19 62 | > 63 | > [Event Driven](#event-driven) 19 64 | 65 | Introduction 66 | ============ 67 | 68 | Current blockchain based virtual machines have inefficiencies in terms 69 | of speed, optimization and cost. Opcodes have fixed execution cost fees, 70 | causing execution to be prohibitively expensive. Execution can not be 71 | parallelized, and each consensus participating node must execute the 72 | state transition to have the same state outcome. 73 | 74 | Fantom proposes an asynchronous, optimized, register based virtual 75 | machine, capable of verifiable computing, while decoupling the token 76 | model to provide a distributed execution marketplace with probabilistic 77 | payments. 78 | 79 | Background 80 | ========== 81 | 82 | Register Based VM 83 | ----------------- 84 | 85 | Virtual machines (VMs) used by existing cryptocurrency platforms are 86 | mostly stack-based, such as the Ethereum Virtual Machine (EVM). 87 | Stack-based VMs can easily execute instructions using the stack data 88 | structure. However, as explained below, stack-based machines have longer 89 | code lengths and slower performance speeds in general compared to a 90 | register-based machines. As a solution to machine. Storage in DAG event 91 | blocks are expensive. As code uses such storage, a large number of 92 | instructions are expensive. **The Fantom Virtual Machine (FVM) intends 93 | to extensively reduce capacity and increase processing speed**. 94 | Publications[1] indicate that register-based virtual machines can reduce 95 | OPCODE execution costs by over 50% and improve performance capacity by 96 | nearly double. 97 | 98 | Stack-Based Model 99 | ----------------- 100 | 101 | The Stack is a basic data structure. A stack-based virtual machine uses 102 | the stack to perform operations. Assuming that we are performing a 103 | simple addition, four command lines are required to perform additional 104 | manipulation using PUSH and POP manipulation. The advantage of a 105 | stack-based model is that the operand is implicitly processed by the 106 | stack pointer: calling a stack pointer provides the next operand (POP), 107 | and there is no need to explicitly state the operand address. In a 108 | stack-based VM, all arithmetic and logical operations work by first 109 | popping and calculating the value pushed on the stack, and then by 110 | pushing the performance outcome to the stack, for example: 111 | 112 | • **LOAD A**: Store Local Variable A to stack 113 | 114 | • **LOAD B**: Store Local Variable B to stack 115 | 116 | • **ADD**: Add the two values 117 | 118 | • **STORE C**: Store operation result to Local Variable C 119 | 120 | Register-Based Model 121 | -------------------- 122 | 123 | In storing the operand, a register-based virtual machine models CPU 124 | registers. While there is no PUSH or POP instruction, a command must 125 | include the name of the pointer, the operand for a command is explicitly 126 | stated. For example, when performing an addition on a register-based 127 | virtual system, the command may be expressed as follows. You can see 128 | that this code is shorter than the earlier stack-based version: 129 | 130 | • **ADD AX, BX, CX** ; Adds AX with BX and stores to CX. 131 | 132 | As previously mentioned, there are no POP or PUSH instructions, so there 133 | is only one line of code. However, unlike a stack, the addresses of 134 | operands, such AX, BX, and CX, must be explicitly stated. On the other 135 | hand, there is no overhead from pushes and pops using a stack, and 136 | accordingly, the command of register-based VM is faster. 137 | 138 | Another strength of a register-based model is that it is possible to 139 | perform optimization which cannot be conducted in a stack-based 140 | approach. For example, if the same calculation is performed twice, the 141 | register model code can be optimized to make only a single calculation 142 | and stores the value to the register for reuse, increasing execution 143 | speed for the code. 144 | 145 | The weakness of a register-based model is that it needs to explicitly 146 | state the operand address, increasing the average size of a command 147 | compared to a stack-based model. While a stack-based VM is very short, 148 | since it does not need to explicitly state the stack address, a 149 | register-based VM must include the location of the operand in OPCODE, 150 | increasing the size of individual commands. However, as was proven by 151 | Dalvik in comparison with the Java Virtual Machine (JVM), the size of 152 | the entire code base can be extensively reduced.[2] 153 | 154 | 155 | = 156 | 157 | Virtual Machine 158 | =============== 159 | 160 | Secure, Powerful VM with Turing-completeness 161 | -------------------------------------------- 162 | 163 | Since we cannot know what types of operations will be needed in the 164 | future, providing Turing completeness is critical for establishment of 165 | the DApp ecosystem. However, providing Turing completeness inevitably 166 | leads to the issue of decision impossibility. To address this, Ethereum 167 | introduced the concept of “GAS” in order to avoid the halting problem. 168 | **However, the amount of gas consumption is hard-coded in the Ethereum 169 | code, and it is impossible to change this flexibly without a 170 | hard-fork.** Also, although operations are critical since it is the 171 | executor who determines whether to perform a contract, inexpensive 172 | programs may or may not perform the operation. The DDOS attack on the 173 | EVM in September 2016 actually slowed down the network speed almost to a 174 | halt, as the attacker was able to attack the network by taking advantage 175 | of low gas prices.[3] Fantom intends to design the FVM with **flexible 176 | execution costs** in mind, with the **authority of the operation node 177 | being limited** as well. Also, Fantom believes that using the **LCA 178 | means that there is no need to execute the same instruction set by all 179 | nodes**. Even if an attack is possible, it should have limited impact on 180 | the network due to its flexibility. 181 | 182 | The issues of security and feasibility are not limited to the EVM – they 183 | are shared by many distributed ledger projects . Some projects (such as 184 | Bitcoin) are mitigating such limitations by removing Turing completeness 185 | or, like Ethereum, by providing a large number of Smart Contract 186 | templates that enable formal verification. However, an absence of 187 | outcome functionality makes it difficult to implement a proper DApp. 188 | 189 | The FVM looks to **provide better security as well as Turing 190 | completeness**. Furthermore, it looks to provide the core functionality 191 | for properly establishing a DApp ecosystem, such as **External Code 192 | Linking, Library, and Import, as well as strong scalability that can be 193 | operated with a grid supercomputer**. **While a Fantom-based Smart 194 | Contract can work in stand-alone, it can also work jointly with other 195 | contracts, functioning as a component of the DApp Infrastructure**. 196 | 197 | Smart Contract Language 198 | ----------------------- 199 | 200 | Fantom provides a **SCALA-like functional programming language for 201 | executing Smart Contracts** on top of its own Virtual Machine known as 202 | the Fantom Virtual Machine (FVM). The FVM will allow executive smart 203 | contract byte code efficiency and across all operating systems 204 | 205 | Scala Based Compiler 206 | -------------------- 207 | 208 | In order to attract vast numbers of developers, Fantom intends to design 209 | a Fantom virtual machine for writing contracts using existing languages. 210 | Scala, a well-known and supported functional programming language, is 211 | intended to be the initial language. The strengths of Scala are 212 | described below. 213 | 214 | Scala, which was developed to remove the inconvenience of Java, allows 215 | developers to write organized and clean code. The strongly-typed 216 | functions of Scala can promote development and improve performance. For 217 | example, functions, macros, and tuples are only a part of the multiple 218 | advanced functions that are provided by Scala. Scala is a well-designed 219 | language which integrates functional and object-oriented programming. 220 | String pattern matching or Mixins, which include functions in class 221 | definitions, make coding enjoyable as well. A language with 222 | comprehensive documentation, Fantom believes Scala is an excellent 223 | choice for developers with any level of experience. Closers and 224 | functions are also a part of the language. The biggest advantage of 225 | Scala is that it provides object-oriented and functional coding 226 | paradigms at the same time. Developers can utilize the two methods with 227 | strength to easily write “concise” and “functional” programs. 228 | 229 | Testing and development are convenient as well. Scala can perform the 230 | same work as Java using smaller coding lines. While Java also has 231 | several methods for reducing the code length, such methods are 232 | deviations from standard coding style, making the code less readable and 233 | leading to reduced productivity. Thanks to the properties of Scala, 234 | coding is reduced and testing and distribution become faster. Scala 235 | includes a non-expanding API library which is concise but possesses all 236 | necessary functions. Writing scalable software using Scala can make code 237 | writing, testing, debugging, and distribution easier. The language is 238 | versatile and can be used in all areas including desktop software, 239 | games, web application programs, mobile solutions, and software 240 | services. It is also a good fit for writing Smart Contracts. 241 | 242 | Scala is a widely used functional programming language. A web App 243 | framework called Play is written in Scala, and it has successfully been 244 | established on numerous IT platforms such as Amazon and Coursera. The 245 | strengths of Scala have already been proven through practical 246 | applications in industry. Haskell, although an excellent functional 247 | programming language supported by mathematicians, does not have nearly 248 | as many users as Scala. Scala is comparatively easy to learn, and is a 249 | popular language with a large community of users. Development is 250 | facilitated since it also supports object-oriented programming. Also, it 251 | has all the strengths of a well-designed functional programming 252 | language. By removing “Side Effects”, many coding errors as well as any 253 | changeable aspects can be identified beforehand, which also allows the 254 | easy transfer of code to a distributed environment. 255 | 256 | **Scala can introduce stringent coding techniques for compilation and 257 | formal verification**. Formal verification is a mathematical methodology 258 | which is used to prove the accuracy of a computer program. This 259 | methodology has been used in protecting the software and hardware of 260 | military systems, transport infrastructure, encryption, and 261 | microprocessors. The value of formal verification in Smart Contract 262 | codes has recently been recognized as well, in particular on the 263 | Ethereum blockchain.[4] 264 | 265 | 266 | 267 | Smart Contract Production Tools 268 | ------------------------------- 269 | 270 | The Fantom Opera chain **provides a Smart Contract script editor**. It 271 | facilitates writing Smart Contracts by **allowing the entry of various 272 | transaction conditions that fit the characteristics of a DApp**. The 273 | Smart Contract script of the Opera chain processes transactions types 274 | that typically arise for each participant in **industries such as 275 | communications, finance, logistics, and electric vehicle provision**. 276 | Smart Contracts are coded in Scala and compiled to bytecode through the 277 | FVM, and therefore have **Turing completeness**. 278 | 279 | Smart Contract Protocol 280 | ----------------------- 281 | 282 | The **Smart Contract protocol is a piece of code that facilitates, 283 | verifies, or executes contract requirements, online without a contract 284 | document or third party. A Smart Contract reproduces the logic of a 285 | contract’s provisions.** 286 | 287 | A Smart Contract, running on a distributed ledger, allows for the 288 | exchange of money, assets, stock, or any other valuables in a 289 | transparent manner without the need for a broker or third party. A 290 | “traditional” contract requires third party intervention from brokers, 291 | government institutions, banks, attorneys, or notaries, as well as the 292 | required processing time, before receiving the goods and services. 293 | However, using Smart Contract technology, much of the above can be 294 | automated. 295 | 296 | This Smart Contract technology could be compared to a vending machine. A 297 | vending machine is designed to run automatically according to 298 | pre-programmed rules, and its output is determined once certain 299 | conditions are met. When using a vending machine, a user deposits money 300 | in the machine and inputs a precise amount, after which the desired 301 | product can be collected. Under a Smart Contract, money will be escrowed 302 | and preserved in the Opera chain, and once certain conditions are met, 303 | will be designed to be immediately transferred to the transaction 304 | counterpart. 305 | 306 | The Smart Contract protocol of Fantom’s Opera Chain processes 307 | transactions that arise between participants according to the conditions 308 | and requirements of each industry. 309 | 310 | Opera’s Story is created when certain conditions within a Smart Contract 311 | are met and the contract is fulfilled, and stores details in the Story 312 | data segment for transactions and Smart Contracts. 313 | 314 | Applications 315 | ============ 316 | 317 | 318 | 319 | Fantom will become the first platform to disrupt the existing 320 | infrastructure for payments and supply-chain management. dApps built on 321 | top of the Fantom Opera Chain will provide transparency and cost 322 | reductions for industries including, but not limited to, food 323 | technology, telecommunication, banking, electricity and real estate to 324 | autonomous vehicles using instant payments with near zero cost while 325 | maintaining hundreds of thousands of transactions per second. 326 | 327 | Example Application: Food Delivery 328 | ---------------------------------- 329 | 330 | An applications written by smart contracts running on the Opera Chain 331 | would be intended to allow consumers to pay costs after ordering food 332 | online and receiving it (or at a predetermined time such as the time of 333 | ordering). A consumer orders food using a food delivery application 334 | host, and sends tokens. Once food is delivered, the transaction tokens 335 | paid by the consumer would be transferred to the restaurant according to 336 | the predefined Smart Contract. 337 | 338 | If food is not delivered properly, consumers would demand the 339 | replacement of food or refund of costs. The smart contract(s) would be 340 | designed to allow the restaurant or the deliverer to make refunds to the 341 | consumer, which is performed by the Opera payment protocol. 342 | 343 | The restaurant or the deliverer would also approve a refund using the 344 | application host (according to the conditions of a Smart Contract). Once 345 | an approval is made, a refund is made according to the predefined Smart 346 | Contract, transferring the corresponding ratio of transaction tokens (as 347 | calculated by the infrastructure algorithm) to the consumer. Restaurants 348 | can also make payments to the application host for advertisements. 349 | 350 | 351 | = 352 | 353 | Research 354 | ======== 355 | 356 | Background 357 | ---------- 358 | 359 | The original design of the EVM was to provide a generalized world 360 | computer. Leveraging the total available resources of the network to 361 | create a new supercomputer. Instead, given how execution occurs, the 362 | network has only as much compute power as the slowest participating 363 | consensus node. Each participant has to execute the full VM 364 | instructions. If execution would take 3 hours to complete, then each 365 | participating node would need to execute the full 3 hours of execution. 366 | For this reason execution has fee and gas limits. These intrinsic limits 367 | do not allow for complex computing or allow for execution capability to 368 | be leveraged on a global scale. 369 | 370 | To achieve a generalized compute engine we need to be able to decoupling 371 | execution and create a bidder based marketplace. Execution itself 372 | however effects state, and as such we still need to apply state changes 373 | without needing to execute the full system state. This does mean that 374 | there needs to be a realistic limit to on-chain state. 375 | 376 | Architectural Overview 377 | ---------------------- 378 | 379 | - Registration, reputation, and transparency in payments and penalties 380 | > for the workers occurs on-chain 381 | 382 | - Workers provide computational power to the system 383 | 384 | - Verifiers are staked entities that issue tasks and verify results 385 | 386 | Off-chain protocol between Verifiers and Workers for execution results, 387 | receipts, histories, and blockchain payments. 388 | 389 | Probabilistic Payment Model that allows for trustless, stateless 390 | payments that scale with number of tasks. 391 | 392 | Trustless Verifiable Computing 393 | ------------------------------ 394 | 395 | The objective is trusted computing. We have a job provider *j*, and we 396 | have a worker *w*, with computation *c(a, b)*. *j* wishes to incentivize 397 | *w* to perform *c(a, b)*. *w* is assumed malicious. *w* could perform 398 | zero calculation and provide output *ϕ*. *j* has no way to verify the 399 | validity of *ϕ*. *j* rewards *w*. 400 | 401 | Strategy One, *j* gives computation *c(a, b)* to *w1, 402 | w2, w3, ... wn*. In order mentioned 403 | they provide *ϕ*, *ϕ*, *ϕ*, 𝜚, *j* can assume *ϕ* is correct. *j* needs 404 | to reward *w1,w2, w3*, till 405 | *wn.* This is consensus based trustless computing. *j* 406 | rewarded for each successful result. *This is expensive.* 407 | 408 | Strategy Two, trusted hardware. Trusted hardware ensures execution. 409 | Intel SGX is the most widely adopted. Requires pre-compilation of *c(a, 410 | b)* into the enclave. Ensures *c(a, b)* is trusted. Cloud providers do 411 | not currently have SGX mass adoption. This excludes a large of a user 412 | base. 413 | 414 | Strategy Three, zk-SNARKs (Strategy Three b, zk-STARKs, not currently 415 | production ready). Trusted execution. Can be deployed to any system, no 416 | hardware limitation, one to one usage. 417 | 418 | We will use libsnark and Zokrates to demonstrate how zk-SNARKs can solve 419 | trustless computing. 420 | 421 | Given function *c(a, b)* we can define it in as 422 | 423 | def main(a,b): 424 | 425 | return a+b 426 | 427 | Compiled via Zokrates, we receive output 428 | 429 | Compiling add.code 430 | 431 | Compiled program: 432 | 433 | def main(a,b): 434 | 435 | return (a + b) 436 | 437 | Compiled code written to 'out', 438 | 439 | Human readable code to 'out.code'. 440 | 441 | Number of constraints: 1 442 | 443 | Now we need to generate proof, given a witness of “a”: 1, ”b”: 1, ”out": 444 | 2 and inputs of 1, 1, 1, 2, we generate proof*π*and verification key *ν* 445 | 446 | Given Proof *π*, and Inputs *i* we can use Verification Key *υ*, to 447 | validate Inputs *i* (public inputs *a, b* and outputs *o*) for 448 | computation *c(a, b)* 449 | 450 | To understand the above, let us discuss interactive proofs in a 451 | practical example. *b* want to buy item x from *a* for 1 token ( *1tk* 452 | ). *a* wants to make sure that *b* has *1tk*, *b* show *a* their wallet 453 | address *0xb*, *a* can confirm it contains *1tk*. *a* is unsure that *b* 454 | is the owner of wallet *0xb*, so they use the public key (or wallet 455 | address) *0xA* to sign message *m*, that creates hash *h*. *a* gives *b* 456 | hash *h*. *b* uses their private key *pk* to decrypt hash *h* and read 457 | message *m*, *b* respond to *a* with message *m* (or instead as answer 458 | to a question phrased in message *m*). 459 | 460 | *a* has proof that *b* owns *0xb*. This was an interactive proof. 461 | 462 | If instead *b* wanted to preempt *a’s* request for proof. *b* could 463 | create message *m* (With the time and *a*’s name) which outputs hash 464 | *h*. If *b* then gives *a* *m*, *h* and *0xb*, *a* can confirm that *h* 465 | was created from *m* by the *pk* for *0xA*. This was a non interactive 466 | (or zero knowledge) proof. 467 | 468 | Consider this same concept for zk-SNARKs, we can confirm that 469 | Verification Key *ν* is generated by compiling *c(a, b)*, and given 470 | inputs *i* and outputs *o* the worker *w* can create a Proving Key *pk* 471 | that can be used along with *ν* to confirm the output. 472 | 473 | This allows us to achieve verifiable computing in a trustless space. 474 | 475 | Trustless VM 476 | ------------ 477 | 478 | We have established that variable computing is possible in a trustless 479 | space. Next, we look at the Virtual Machine. 480 | 481 | A Virtual Machine (VM) is an encapsulated execution environment. 482 | Following our previous example of Worker *w*, Job Provider *j*, and 483 | computation *c(a, b)*, *w* does not wish to execute arbitrary function 484 | *c(a, b)* provided by *j* since *j* might be malicious and attempt to 485 | damage *w*’s systems. So instead *w* executes *c(a, b)* in a virtual 486 | machine. 487 | 488 | The VM does not execute *c(a, b)*, *c(a, b)* is compiled to bytecode *b* 489 | and then *b* lives inside the VM. This then allows *b:c(a, b)* to be 490 | called. 491 | 492 | The above separation is important for understanding the (Ethereum) 493 | Virtual Machine. 494 | 495 | At the bottom layer we have the VM (EVM), as the second layer, living 496 | inside of the EVM we have the binary (compiled contracts and Application 497 | Binary Interface (ABI)), and at the top layer we have solidity 498 | contracts. 499 | 500 | For those familiar with Java, this is the same as the JVM (Java VM), 501 | ByteCode (class files) and Java source code. We would have 502 | HelloWorld.java, compile it via the Java Compiler (javac) to 503 | HelloWorld.class, and then we can execute via the JVM. 504 | 505 | For the EVM, we have HelloWorld.sol, we compile and deploy to address 506 | *0xc*. We can execute functions inside of *0xc*. 507 | 508 | Consider *0xc* as the address pointer. 509 | 510 | For this article, we consider a stateless EVM. No data will be saved. 511 | Consider the stateless function; 512 | 513 | def f(a,b): 514 | 515 | return a+b 516 | 517 | Two important parts here. One, did the EVM compile the code correctly, 518 | and Two, if we execute *f(1, 1)*, does it execute correctly. 519 | 520 | For both of these, we provide a zk-SNARK enabled compiler, and a 521 | zk-SNARK enabled EVM. 522 | 523 | Execution of *f(a, b)* will provide witness “b" : 2, ‘a" : 1, “out0" : 3 524 | as well as the Proving Key *pk*. 525 | 526 | Execution in the EVM (or other compatible VMs) is ensured in a trustless 527 | environment. Consensus is no longer required for execution, EVM 528 | processing can be asynchronously parallelized, allowing for trusted 529 | off-chain execution. 530 | 531 | Stateless Computing 532 | ------------------- 533 | 534 | The above however describes stateless computing. 535 | 536 | Use cases include; 537 | 538 | - Machine Learning 539 | 540 | 541 | 542 | - Protein Folding 543 | 544 | 545 | 546 | - Image classification 547 | 548 | For dApps stateful computation is required. Standard options are 549 | available; 550 | 551 | - IPFS 552 | 553 | 554 | 555 | - Standard centralized data stores 556 | 557 | 558 | 559 | - Anchoring Chain 560 | 561 | - Decentralized Storage 562 | 563 | To achieve state we must defer to consensus. Current options; 564 | 565 | - Each node executes the full state transition (Ethereum) 566 | 567 | 568 | 569 | - State updates are applied after verification (Leader based) 570 | 571 | 572 | 573 | - State differences are applied after attestation 574 | 575 | In TEE or Zero Knowledge proof systems attestation can be used. 576 | Attestation could be more expensive than the actual execution. Also has 577 | concerns towards forked states and resolution. 578 | 579 | Achieving Fast Attestations 580 | --------------------------- 581 | 582 | We will use graph computation algorithms to achieve fast attestations 583 | among a large-scale network of distributed nodes. 584 | 585 | We use mutual attestations and gossip protocols among nodes to 586 | collaboratively construct a web-of-trust. 587 | 588 | A node attests the integrity of other nodes. It collects the attestation 589 | results. which are modelled as its Direct trust to a target node and 590 | stored in its local database. 591 | 592 | Di,j(*t*) = *Σ**tn* 593 | *ϵ*AHj(*t*)2k-*δ*(t(tn)) 594 | 595 | *Di*,j(*t*) is calculated by combining the 596 | timestamps maintained in the attestation history, which records the 597 | attestation tickets towards the neighbour (*Nj* ). It is an 598 | integer interpreted as a bitmap vector with the length of *k*. Each bit 599 | represents a timestamp one step away from its higher adjacent bit, and 600 | the highest bit indicates the time *t*. A bit is set to 1 when an 601 | attestation is performed at the step it stands for. Thus, the direct 602 | trust, calculated as above, reflects all the recent successful 603 | attestations up to time *t*. *AHj(t)* denotes the attestation 604 | history for node *N*j at time *t*. As a step is defined as 605 | minimum attestation interval, different timestamps *t* in *AH* do not 606 | indicate a same bit index. We can thus safely use summation instead of 607 | bitwise OR (“\|") for setting the corresponding bits. 608 | 609 | This definition allows two evaluation values be compared. The larger one 610 | indicates the more recent an attestation is performed, and hence 611 | indicates a higher trust credibility. This property is used for 612 | modelling the Transitive Trust. 613 | 614 | Direct trust values are propagated among the logical surrounding 615 | neighbours by exchanging the corresponding kernel contents using the 616 | gossip protocols. Therefore, from the kernel, a node is able to 617 | determine how its neighbours attest to each other. This thus helps 618 | modelling the Transitive Trust, which is represented by a path of 619 | connections. 620 | 621 | The gossip protocols allow each node to disseminate the trust 622 | relationship it gathers to other related nodes, so that redundant 623 | attestations will be reduced. There are three ways of gossip 624 | dissemination; 625 | 626 | - Gossip about gossip: when the local node and a target node only have 627 | > few common in their Kernels, the gossip about gossip protocol is 628 | > initiated to directly exchange their Kernels. 629 | 630 | - Gossip about reduced gossip: when the local node and a target node 631 | > have much common in their Kernels, the gossip about reduced gossip 632 | > protocol is initiated to only exchanged the complemental parts. 633 | 634 | - Targeted gossip: any time when a local node updates its Kernel, it 635 | > identifies the set of target nodes who will be benet from the 636 | > updated data and sends the updated data package directly to the 637 | > set of nodes. 638 | 639 | Gossip about gossip enforces batched exchanges of attestation 640 | relationship data, this allows a new node to quickly obtain the 641 | up-to-date global data. Reduced gossip allows two “not-too-closed" nodes 642 | to exchange their data in batches, while reducing networking overheads. 643 | Targeted gossip allows new attestation relationship information to 644 | quickly propagate among the “closely-related" nodes to without putting 645 | too much burden on the network traffic. 646 | 647 | The combination of these three gossip strategies achieves both quick 648 | information propagation rate with low networking overheads. With 649 | transitive trust relationship gathered by remote attestations and gossip 650 | protocols, The graph further builds a\`Conspiracy Breaching' model for 651 | nodes to illustrate how intense a target node is attested by other 652 | nodes. This model helps locating the nodes who have the greatest 653 | \`diculties to lie'. Meanwhile, small world network algorithm improves 654 | the networks' robustness. 655 | 656 | Execution Trust 657 | --------------- 658 | 659 | Even at a software architectural level we can assume the above gossip 660 | about gossip protocol to achieve a trust score for adjacent nodes and 661 | spread this information via a graph structure. This allows us to achieve 662 | trust ratings, this could branch out into one of two choices; 663 | 664 | - High trust score, apply state diff 665 | 666 | - Low trust score, execute state transition 667 | 668 | Decoupling Token Value 669 | ---------------------- 670 | 671 | A fee based token economy marketplace will be used to ensure fair value. 672 | 673 | Tasks are associated with a bid: the amount of coin offered for 674 | performing the task. Bidders can adjust the bid on their pending tasks 675 | to expedite their execution. Workers will decide if a bid is sucient for 676 | them to execute upon. Since this is a competitive market, workers will 677 | execute work when profitable for them to do so. 678 | 679 | When work is completed the attestation and state diff are provided. The 680 | state engine updates state diff based on attestation score and assigns 681 | the bid to the workers coinbase. 682 | 683 | Pledge Penalty 684 | -------------- 685 | 686 | Workers will submit a signed pledge of staked coins as collateral. This 687 | becomes forfeit if attestation proves malicious behavior. 688 | 689 | Contract Life Cycle 690 | ------------------- 691 | 692 | User *a* creates ERC20 smart contract *sc* 693 | 694 | def transfer(to,val): 695 | 696 | to.add(val) 697 | 698 | this.from.sub(val) 699 | 700 | Compute nodes need local state as well as a global shared state. (State 701 | Redundancy) 702 | 703 | Transaction in Ethereum are ACID (Atomicity, Consistency, Isolation, 704 | Durability)[5]. 705 | 706 | For scalability this should be BASE (Basically Available, Soft state, 707 | Eventual consistency)[6]. 708 | 709 | We assume *n* nodes in the ecosystem. 710 | 711 | We assume *k* nodes are willing to execute an instruction. 712 | 713 | *k/n* nodes create *sc.* 714 | 715 | *k/n* nodes provide attestation and state trie. (Redundant step\*) 716 | 717 | *a* has a balance of 10, *a* sends 10 to *b* in *tx1* and 10 718 | to *c* in *tx2* 719 | 720 | Compute Node *cn1* processes tx1, valid state. 721 | 722 | Compute Node *cn2* processes tx2, valid state. 723 | 724 | Consensus layer can only accept one state and must inform the other of 725 | incorrect execution. 726 | 727 | Privacy Preserving 728 | ------------------ 729 | 730 | Encrypted state 731 | 732 | Additional Improvements 733 | ======================= 734 | 735 | FastVM 736 | ------ 737 | 738 | - Reducing the data word size from 256 bit to 128 bit 739 | 740 | - Introducing LLVM JIT as the execution engine 741 | 742 | [https://github.com/aionnetwork/aion\_fastvm](https://github.com/aionnetwork/aion_fastvm) 744 | 745 | Solidity++ 746 | ---------- 747 | 748 | - EVM compatibility 749 | 750 | - Asynchronous Semantics 751 | 752 | - Contract Scheduling 753 | 754 | - Standard libraries 755 | 756 | - String manipulation 757 | 758 | - Floating-point operations 759 | 760 | - Basic mathematical operations 761 | 762 | - Containers 763 | 764 | - Sorting 765 | 766 | Event Driven[7] 767 | --------------- 768 | 769 | In the protocol of Ethereum, a transaction or message may affect the 770 | status of multiple accounts. For example, a contract invocation 771 | transaction may cause the status of multiple contract accounts to change 772 | at the same time through message calls. These changes occur either at 773 | the same time, or none at all. Therefore, the transaction in the 774 | Ethereum is actually a kind of rigid transaction that satisfies the 775 | characteristics of ACID (Atomicity, Consistency, Isolation, 776 | Durability)[8], which is also an important reason for the lack of 777 | expansibility in the Ethereum. 778 | 779 | Based on considerations of scalability and performance, we adopted a 780 | final consistency scheme satisfying BASE (Basically Available, Soft 781 | state, Eventual consistency)[9] semantics. 782 | 783 | Specifically, we design an Event-Driven Architecture (EDA)[10]. Each 784 | smart contract is considered to be an independent service, and messages 785 | can be communicated between contracts, but no state is shared. 786 | Therefore, we need to cancel the semantics of synchronous function calls 787 | across contracts, and only allow message communication between 788 | contracts. The EVM instructions affected are mainly CALL and STATICCALL. 789 | These two instructions can’t be executed immediately, nor can they 790 | return the result of the call. They only generate a request transaction 791 | to write to the ledger. Therefore, the semantics of function calls will 792 | not be included in this instruction, but rather sends messages to an 793 | account. 794 | 795 | [1] Yunhe Shi, David Gregg, Andrew Beatty. Virtual Machine Showdown: 796 | Stack Versus Registers. 2005. 797 | 798 | [2] David Ehringer. The Dalvik Virtual Machine Architecture. p5, 2010. 799 | 800 | [3] https://blog.ethereum.org/2016/09/22/ 801 | ethereum-network-currently-undergoing-dos-attack/ 802 | 803 | [4] http://antoine.delignat-lavaud.fr/doc/plas16.pdf 804 | 805 | [5] Theo Haerder and Andreas Reuter. Principles of transaction-oriented 806 | database recovery. ACM Comput. Surv., 15(4):287–317, December 1983. 807 | 808 | [6] Dan Pritchett. Base: An acid alternative. Queue, 6(3):48–55, May 809 | 2008 810 | 811 | [7] https://www.vite.org/whitepaper/vite\_en.pdf 812 | 813 | [8] Theo Haerder and Andreas Reuter. Principles of transaction-oriented 814 | database recovery. ACM Comput. Surv., 15(4):287–317, December 1983. 815 | 816 | [9] Dan Pritchett. Base: An acid alternative. Queue, 6(3):48–55, May 817 | 2008 818 | 819 | [10] Jeff Hanson. Event-driven services in soa. URL 820 | https://www.javaworld.com/article/2072262/soa/event-drivenservices-in-soa.html. 821 | --------------------------------------------------------------------------------