Yes, I spent the last months on the Ethereum/Blockchain topic. From my perspective this is one of the technologies that will change the way we are interacting with the internet.
But as with any other technology it is still evolving and scalability is one of the big problems. One can see that e.g. the Bitcoin blockchain blocks are already saturated and does not scale further. The throughput is something about 8 Tx/s, means not even close to a direction where one can think on some more serious usecases. Ethereum blockchain has in principle the same limitation as the Bitcoin blockchain, but the focus is not just the "transfer" of values, but the execution of so called smart contracts. There is a interesting post from Vitalik regarding scalability : https://blog.ethereum.org/2014/02/18/ethereum-scalability-and-decentralization-updates/ Means a combination of different aspects like sharding,.. asynchronous processing may improve the scalability a lot. From my perspective we have to talk about different security and the need-for-general-consensus profiles as e.g sensor contract does not have the same requirements as e.g. a payment (value transfer) transaction. So yes, there are still open issues, but I;m convinced that they will be solved. One idea in this context. Actually there is now no real Index for the blockchain. One can query in blockchain by Id, as sites like https://www.etherchain.org/ are doing - simply indexing the blocks by block Id. Since the contracts can store arbitrary data (states) it will be cool to perform a query like : Select Contract c where c.version == 1 and c.status = 'executed' and c.amount > 10 This is not yet possible and I;m thinking to build something on top of Zest using : - https://github.com/ethereum/ethereumj // blockchain access - http://www.antlr.org/ // ASTs from the solidity contracts to be able to access/identify the properties Since Zest has already the Store/Index separation, it should not be that hard. I;m still not yet done conceptually, but my impression is that it should work. Cheers, Jiri 2016-02-14 17:35 GMT+01:00 Niclas Hedhman <[email protected]>: > Yes, it is all about IoT. > > About Ethereum; Have you gotten a good insight in this? I know what a > blockchain is, but assuming a million sensor generating 12 values per hour, > we are talking GBs per hour of data added... And 1 million is hopefully on > the low end. > > I would love to hear more about it... > > Cheers > Niclas > > > On Sun, Feb 14, 2016 at 11:55 PM, Jiri Jetmar <[email protected]> > wrote: > > > Hi Niclas, > > > > so you are hacking now on hardware ? Interesting.. Just curious - what is > > that unique on a ESP8266 > > based temperature sensor ? Does it go to the direction of IoT ? > > Independently of that - if you need some, I can surely help you. And to > > "burn" a new firmware should not > > be a big problem.. :-) > > > > An idea on this topic. You mentioned you are building the backoffice for > > the sensor as well. What about > > to pipe the sensor data to a blockchain ? Means to build a smart contract > > and let the sensor write the data > > directly to such a contract : > > > > contract SimpleStorage { > > uint storedData; > > > > function set(uint x) { > > storedData = x; > > } > > function get() constant returns (uint retVal) { > > return storedData; > > } > > } > > > > This is a solidity ethereum.org contract to simply store data. One can > > extend the concept and charge some little money > > from those parties who wants to "get()" some data and hence the sensor > can > > pay for him self. > > > > Cheers, > > Jiri > > > > > > > > > > 2016-02-13 4:58 GMT+01:00 Niclas Hedhman <[email protected]>: > > > > > Gang, > > > > > > I haven't had much time on Zest lately, as I have been busy creating a > > > low-costWiFi capable, USB-powered temperature sensor. See > > > http://hedhman.org/~niclas/IndoorioD.jpg > > > > > > And for the fun of it, I ported FORTH programming language to the > ESP8266 > > > CPU that is on this, in Assembler of course. Interpreter, Compiler, > base > > > vocabulary (functions) and REPL in ~1000 assembler instructions, and > the > > > full vocabulary in another 10kbytes or so. It has been a lot of fun. > > > > > > This little puppy will go for one more round of prototypes next week, > as > > I > > > want to add an external watchdog and tiny prototyping area for maker > > > community. Then I intend to make a field test with 100 units or so. > > > > > > So, why am I telling you all this? > > > > > > First of all, these guys will report the temperature back to a central > > > server every 15 minutes or so. And the management system on the server > is > > > written with Zest. The rest is with Grafana and ElasticSearch. I am > > > considering trying to build a business around data capture, > aggregation, > > > analytics and visualization. Anyone interested to join? > > > > > > Secondly, I am looking for volunteers for my field test. It will > probably > > > happen in April or so. If you participate, you will receive a USB > powered > > > sensor as seen. Plug it into power somewhere for 6 months, connect to > it > > > over WiFi, configure it to use your WiFi router over a simple web > > > interface, and keep it powered for 6 months. > > > If there are problems, I might ask for reboot. Hopefully not any > firmware > > > upgrades. > > > > > > Let me know if you are interested in this. > > > > > > > > > So, as the device design and software is soon coming to a good state, I > > > will return my focus on the central server, which means that I will get > > > back to Zest development shortly. It has been far too quite recently. > > > > > > > > > Cheers > > > -- > > > Niclas Hedhman, Software Developer > > > http://zest.apache.org - New Energy for Java > > > > > > > > > -- > Niclas Hedhman, Software Developer > http://zest.apache.org - New Energy for Java >
