Synereo Weekly Update
Update Summary
Synereo and Ethereum now have an end to end spec of a correct, fault tolerant architecture that is sharded, i.e. scales and allows to constrain the behavior of nodes for the purpose of reaching consensus about the next block to be added to the new Proof-of-Stake based blockchain. Economic-, security- and game-theories have been taken into account and all fit within the framework; everything can be worked out now!
Ed gives a demo of LivelyGig. Gary is working on weWOWwe now. HJ shares comments about onboarding. Shared infrastructure is in the works, and being financially supported. The discussion ends with a long discussion about governance and freedom.
Contents in Brief
00:20 — Quick updates
06:30 — Demo of Livelygig
12:59 — Gary Stephenson, working on weWOWe
14:40 — One click deployment
17:00 — Agreement with Livelygig
20:25 — Graphic Designer Noy
21:20 — Governance issues and design
36:25 — Is HJ boarding on?
41:00 — Discussion about governance and freedom
57:00 — Casper progress
1:10:55 — Casper is defined!
0:20 — Quick updates
Ian discusses several conference call solutions for the 15-minute standup. He’s going to implement a Jitsi server on Google. Dor said that the $100,000 grant for cloud services on IBM or Google could be used for that. AWS is solely used for hosting Synereo nodes.
06:30 — Demo of Livelygig
In the doc Splicious Session Traffic Cam, how posts are handled on the server is explained(“evalSubscribeRequest” and “evalSubscribeResponse”).
Here you see the exact syntax that’s coming back from the server: “pageOfPost”
Here you see how it is rendered to the webpage.
The next step is how to send a query to the server and how to set the labels.
Ed is working on the conceptual work-around contracts and their various stages: Initiating, Escrow, In Progress, Feedback.
10:15 — Escrow part of the puzzle
Ed asks how escrow can be formed with a currently existing bitcoin-wallet, so that private and public keys of a bitcoin don’t have to be in a browser session. To be discussed In the next Hangout.
12:59 — Gary Stephenson is working on weWOWwe
Gary has now all the pieces together to stand up a node. All sessions with Greg are recorded and explain how to do this. Gary is going to help out with the work involved with the weWOWwe development. Jitsi is used for hangouts, it has no problems like Skype has in China.
14:40 — One click deployment
LivelyGig converted the AWS-ami into AWS-vdi. Probably this VDI can also be converted into a Docker image as well. However all those implementations are still based on the older node, until Dory (@nodes) gets all the dependencies of the different components upgraded to the newest versions. The hope is that in the coming year the amount of components are reduced, and that Synereo will have developed its own versions of those components. That would give more control over the whole platform.
17:00 — Agreement with Livelygig
Synereo will financially support the work of Nirvanic on the shared infrastructure. The idea is that new decentralised services can use that shared infrastructure as a kind of template. Eric and Dina will be the product managers of developing the UI modules and they will have a DEV-team that’s going to support them. They will use some basic ideas from Synereo’s currently available UI. The plan is to the release the product in sync with the upcoming crowdsale.
20:25 — Graphic Designer Noy
Noy has done already stunning design work for Synereo — and she’s at it again!
21:20 — Governance issues and design
Jed and HJ will go over this in the next hangout. Currently Taiga is becoming a kind of project management tool where tasks are registered and assigned to persons. There are thoughts about how people can help and influence the decisions on how Synereo will take shape.
Dor talks about the idea of how a company that drives a community can operate in the most distributed and decentralised way, and how investors that support these ideas can participate in a crowdsale as in BTTF. Most investors invest the minimal amount of $1000.00, only a few invest 10 fold or 100 fold that amount. So maybe it’s necessary to set a maximum cap that can be invested by one entity, like 1% or 3%, in order to avoid that one entity gets a share in the company of 30%. Because that goes along with privileges: a vote, or a say about how Synereo is developing. Synereo wants to keep its current vision up and to practice how distributed decentralised governance is actually done. Maybe a parliament construction. Examples are Liquid democracy. Slowly Synereo wants to involve the community more and more into the decisions that have to be made.
36:25 — Is HJ boarding on?
HJ wants to get more involved in Synereo, as the community manager. Congrats and Welcome HJ!
41:00 — Discussion of governance and freedom versus order
Eric sees some similarities between designing the crowdsale on BTTF, i.e. getting FIAT-investors into Synereo Ltd., and getting users into the Synereo network with AMP’s and REO. Dina suggested to lock some AMPs when new users join Synereo that they can use only in the Attention Economy. Next week some visual designs will be shown, that work out these ideas. See also the discussion on Any other libertarians here?. This is a matter of trust and control that humanity has always faced. Taking on responsibility is not the same as relinquishing freedom. Capital equals influence is a path that’s now well explored and it leads to catastrophic outcomes when it’s unbalanced.
Eric brings up Dor’s post on the forums about order versus freedom as the social order scales up.
57:00 — Casper progress
How to recognise the means of synchronisation in the π-calculus? — it’s all about matching inputs to outputs. That’s the essence of the π-calculus model that could be somehow related to the consensus model of Casper. The first step is to make the π-calculus so that it allows for reflection. That means that there’s a relationship between names and processes.
The constructs that you need:
Construct Explanation x?( y )P is a process on channel x that is waiting for some input y before it continues with P x!( Q ) is a process on channel x that is going to send something Q, that is actually some code that’s going to be sent *x since names are the codes of processes you ought to be able to take the code of a process that you receive and that you can turn back into a process (turning code back into a process) P|Q are processes that run in parallel 0 is a stop process
In higher order π-calculus, not only the names of process/channels travel around, but also the code of processes moves around. That’s why it’s called reflective high order calculus.
The two line rule that make the core engine of computation says (COMM):
If channel x_t the target of communication matches somehow x_s the source of communication then if you have x_t?( y )P, i.e. a process on the target channel x_t that’s waiting ? for some input y running in parallel ** ** with x_s!( Q ), i.e. a process Q that’s ! outputting on x_s the source channel, then -> the data flows and then everywhere inside y the process where it needed the data. It is replaced by the data that it received, which is P{ @Q/y } the code of the process.
This synchronisation will make Casper’s consensus algorithm. So the idea is that you replicate a bunch of π-calculus machines and then the only state that you need consensus about is the consensus on which of these communications actually happen. The consensus is determining when source meets target.
x_s could be names, for example a URL
If you say your matching rule is this: match( x_t, x_s ) := x_t = x_s
You say x_t the target URL is the same as x_s the source URL
But you can be much more sophisticated…
What we have now is a complete description of how to have replicated specialK machines that manage blockchain state and do so in a provably correct fashion. And the transition between blockchain states is done by Casper consensus. And then the final point is that the consensus game becomes a reflective π-calculus process. The final step is to implement metering of the steps that the machines take, see below.
1:10:55 — Casper is defined!
So what we now have is an end to end spec of a correct, fault tolerant architecture that is sharded, i.e. scales and allows us to control the behavior using behavioral types. Economic, security and game theories have been taken into account and all fit within this framework. Everything can be worked out now.
That’s all for this week! See you on next week’s Hangout.
Originally published at blog.synereo.com on March 16, 620.
