Note: This RFP is open to you. You are asked to submit proposals if you are competent in this area and the money will go to you if your application is successful upon completion of the work proposed. Please send all proposals to: rfp2016 <at> decred.org Closing Date All proposals must be submitted by 06:00 PM UTC May 22nd, 2016. Description There exists no easy way to generate transaction scripts, such as smart contracts. To facilitate more extensive use of the scripting system, a higher level language is required. Requirements Experience with Bitcoin and Decred's native scripting language Prior work in compilers, development of higher level languages, and compiler optimization Scope A new higher lever language needs to be developed for Decred's transaction scripting system. This should enable the end user to create simple functions using passed stack items as arguments. It should allow them to declare and alter local variables, make use of all available generic operators, and incorporate new speciality operators such as OP_CHECKSIG. It should be well documented and extensible to new OP codes that Decred may add in the future. The language should support the ability to call simple user designed functions within the main statement, and compile these into a larger, comprehensive byte code script. An example of an attempt at such a language can be viewed in this repository, for Bitcoin script: https://github.com/curiosity-driven/bitcoin-contracts-compiler The language should have the ability to optimize the bytecode of these scripts using the abundant stack manipulation OP codes found in Decred's transaction scripting language. Typing should be strong, with the ability to cast between types and compilation failing if types are inconsistent. Because of the simplicity of the scripting language, compilation to an intermediate representation (IR) is probably not necessary because it will end up so close to compiled byte code itself. Estimated Work 8 weeks FTE or greater (1 FTE = 40 hrs/week). Proposal Proposals should include: Outline and specifications of the syntax and lexer/parser for the language References to prior work on compilers and language design Estimated completion time Milestones Partial payments shall be made at the following milestones: Specifications of all logical statements, operators, and other symbols for the language Implementation of the higher level language with a large suite of examples and tests demonstrating functionality and robustness Further optimization of the byte code for efficiency, then enhancements and modifications of the language based on feedback from developers Modification of these proposed milestones is acceptable, and must be accompanied by sound reasoning in a proposal. Under no circumstances shall payments be made in advance of work being completed.
Dropping some links here that I found related. compete with this, http://solidity.readthedocs.io/en/latest/ Solidity..the smart contract language for ethereum. for the broad view you should look at http://rootstock.io/ too The Decred bytecode/VM is completely different then eth and has much more in common with Bitcoin Decred VM op codes: https://github.com/decred/dcrd/blob/master/txscript/opcode.go#L37-L300 EVM op codes: http://ethereum.stackexchange.com/questions/119/what-opcodes-are-available-for-the-ethereum-evm some examples of contracts on solidity https://etherchain.org/contracts you can view their code, https://etherchain.org/account/0xf45717552f12ef7cb65e95476f217ea008167ae3#code here is some more documentation on opscode from bitcoin https://bitcoin.org/en/developer-reference#opcodes you should probably have these too, from the inventor http://szabo.best.vwh.net/smart_contracts_idea.html http://szabo.best.vwh.net/contractlanguage.html the ethereum white paper http://vbuterin.com/ethereum.html and this is kind of the end goal, https://daohub.org/ to bring this capability to decred. https://forum.decred.org/threads/decred-development-as-a-dao.3471/
Here is a different take on how to implement smart contracts and oracles. http://www.ibtimes.co.uk/jeff-garziks-bloq-runs-smart-contracts-like-ethereum-plug-bitcoin-1561976 Jeff Garzik's Bloq runs smart contracts like an 'Ethereum plug-in for Bitcoin' "Bloq's smart contract application is a piece of software called Bloq Ora (short for oracle). It allows users to run their favourite programming language, Java, JavaScript, Python, C++, and write Turing-complete smart contracts on any blockchain. It's essentially designed as an Ethereum plug-in for Bitcoin. But it has several qualities that make it, in my opinion, better than Ethereum, where you have to learn a new programming language, you have to download a new debugging software, new development tools, everything - sort of the ink is not yet dry. You contact five companies running Bloq Ora and they each execute the smart contract in exactly the same fashion. Then you verify that at least three of five of those companies' Bloq Ora instances return the same answer."
If Decred's network decides to implement a smart contract setup, and it is not using a current fundamental language I am not even interested. To clarify, not interested in scripting on the Decred network in such a sense. The language needs to be known, such as Javascript, etc. The community should head over to Lisk.io and check out how to write smart contracts on their network. Such a system would be wonderful for Decred and pull more interest from the wider community. I like Ethereum but HATE Solidity. Such a language will heighten the barrier of developer adoption. Let's not do that to Decred .
So that the 10% developer subsidy fund can be controlled and distributed by community voting, similar to how PoS voting works, instead of held centralized by company0.
Thank you for the information posted here. There's been some good discussion on the topics raised, so let's see if we can move that discussion to the Governance section. I've collected a number of people's thoughts on the topics, and don't want to detract from the technical outcomes of RFP-8 specifically (even though the topics relate to those outcomes). I think it's a good opportunity to stimulate discussion on some broader questions too, which is what we need as a community and project before heading into any single direction.
Thank you for the proposals submitted. Congratulations to @kefkius for his successful proposal! He has done a tremendous amount of work on the topic already and brings a lot of experience to the project, some of which include: txsc - a transaction script compiler, which is loosely based on the Superscript compiler. Hashmal - an IDE for transaction scripts that makes it easier to write, evaluate, and learn about scripting. It can write scripts in human-readable form, observe the stack as scripts are executed, see explanations of scripts as they are evaluated, generate transaction scripts using templates, deserialize and build transactions, deserialize blocks, communicate with full nodes or block explorers to retrieve blockchain data, and encode and decode addresses. @kefkius will now join the project and work with Decred developers to complete the milestones described. This is an exciting area of research and work that opens up very interesting avenues for users, so be sure to check out this thread for updates on his progress and for technical discussion as it develops!
Thanks! I'm looking forward to this a lot. I think that this project will indeed open up some new and interesting possibilities.
Promising that we have been able to finally award this to a competent developer. @kefkius if you need any help with the project, my knowledge lies in ruby/php/js syntax's.
Progress has continued steadily on this RFP. The specifications are up here: https://github.com/Kefkius/txsc/tree/master/doc The first milestone should go out soon. The implementation is currently a work in progress and many bugs are being shaken out. Syntactically it's similar to other C-like languages, and is being developed with security and simplicity in mind.
Couple links, possibly relevant, pls check : https://github.com/ethereum/wiki/wiki/Serpent https://z.cash/blog/zksnarks-in-ethereum.html Can not vouch for correctness, but I share the fear of contracts in general ... http://nakamotoinstitute.org/mempool/ethereum-is-doomed/