James Platt writes: > On Mar 16, 2021, at 3:24 PM, Christopher Lemmer Webber wrote: > >> But "smart contracts" is a use case, a broad problem domain. What kind >> of smart contracts are you wanting to write? > > I do need to research the topic a bit to make sure that what I want to > do is possible but, according to what I understand so far, it's > actually a clearer use case for smart contracts than most. I want to > use them to promote reproducibility of scientific data analysis. The > idea would be that you put your data analysis together as a smart > contract and then others can run it again and be much better assured > of getting the same result than they would be without the smart > contract. As I understand it, one of the big issues with smart > contracts for work transactions is that there could be a bug which > causes your contract to enforce something a bit differently than you > intended. This is quite different from traditional business contracts > where, if it comes to a lawsuit, the courts will look for the intent > of the contract. My use case is only asking for reproducibility. > > The big difficulty for my use case is that you have to be able to tie > into various different bits of code previously published by others. > For example, a DNA sequencing analysis pipeline which I worked with, > had various parts of the process written in Perl, Python, C, R, JAVA, > javascript, UNIX shell script, and AppleScript, much of it published > by people outside my lab. So a lot of that would probably have to be > outside the contract. However, you need a "glue language" to put it > all together. We were using shell script for that because most of it > needs to run on a supercomputing cluster. We looked for something > that could make the code more understandable. Python was a > possibility but we were leaning towards Big Data Script (BDS) which is > a DSL specifically for this purpose. In any case, if something like > BDS (as a glue language) were implemented as a smart contract > language, that would at least take care of the top level. > > Later on, it would be great to be able to buy and sell resources on > our P2P network with a cryptocurrency. This would include storage, > bandwidth, and processing time for intensive computations. You would > be able to buy and sell smart contracts using these things. I > understand that Etherium can do things like this but there are quite a > few technologies to read up on, starting with Subutai, > https://subutai.io.
You may enjoy reading the "72 Hours to DonutLab" writeup. https://www.hpl.hp.com/techreports/2005/HPL-2005-5.html Again, pre-blockchains. This is using the E programming language on which Spritely is based. As you can see, it's even listed on the E website under "smart contracts": http://www.erights.org/smart-contracts/index.html As for running external programs, these can be contained; SandStorm did a nice demonstration of how to do this. Guix Workflow Language might also be an interesting source of inspiration, even though I'm not suggesting it exactly be what you use. However, I'd be cautious about drinking too deeply into the blockchain hype; the things you'd like to accomplish can probably be accomplished just as well with an E-style mint, as I referenced earlier. But yes, you can compose blockchains with this too... but more importantly, the abstraction layer can be *general* enough to not use a *specific* choice of a cryptocurrency approach. Beware of someone trying to sell you otherwise on some ICO. The way that blockchains can just be perceived as mutually-executed machines on the network (in that sense, "decentralized centralization" converging on a single machine in the network, reproduced in multiple places) is probably best explained by this talk: https://www.youtube.com/watch?v=YXUqfgdDbr8 With the abstractions Mark talks about in that talk (ERTP), you can use a blockchain... but also plenty of non-blockchain components which might work just as well for your usecase. But then you haven't tied yourself to a specific approach. Generalize appropriately. - Chris -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/87o8fg17do.fsf%40dustycloud.org.
