polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Jetmar <juergen.jet...@gmail.com>
Subject Re: Update from Niclas
Date Sun, 14 Feb 2016 17:23:58 GMT
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 <niclas@hedhman.org>:

> 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 <juergen.jetmar@gmail.com>
> 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 <niclas@hedhman.org>:
> >
> > > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message