Introducing BitShares Object Graph

[luckybit]

groundbreaking and thought provoking! 

u mistyped primtive btw.

Ethereum stuck to primitives or assembly.. And a double directed graph would cut down dev costs and ease of use on primitives.. however the million dollar question is: Is there a case you can think of where you would not want to use a graph but use primitives to solve a problem?

I guess vitalik assumes others will build on top if there is a market todo so while we give a leg up on beginners to solve problems quicker but if its a subset of problems then there is a case for primitives or assembly still.  That is when will flexibility of primitives be needed in this context where a graph wouldnt work for a layman?

It's also possible that Vitalik simply over looked this. Building something like Ethereum is hard but I think if you're going to build a scripting language you need to make it high level. Right now they have scripting but as a person who can read several programming languages their scripting is awkward and low level.

I think now that they have the resources the Ethereum team should make a scripting language as much like Python or Javascript as possible. You want something which has minimal syntax for people to learn and which is powerful enough to do the job. Python is good as a scripting language because it's powerful but the syntax is very simple.

Serpent is supposed to be like Python and it's getting closer but it's not quite there. I think the competition between Bitshares and Ethereum should be on making it easy to develop for. Whichever DAC is easier to develop for will certainly win over my attention and I would think most people who aren't rock star developers at the same way.

C++ is not the language people will want to mess with when dealing with people's money. Javascript on the other hand is easy and so is Python. If it is easy people will feel confident enough to write code and if projects can be completed in weeks instead of months people will be more likely to make time to do it.

[luckybit]

This is the most confusing exciting news I've heard all week.

Better than ethereum is enough for me.

 

My take on it as someone who knows C++ enough but who is not a rock star developer is that one of the keys to success is having an attractive developer environment. High level developers who are interested in scripting will find Object Graph to be extremely important. Object Graph can do most of what people will want to do and lay the foundation which can be built upon.

I think this give Bitshares the edge now over Ethereum. Ethereum's development environment is too complicated and needs to be abstracted. The community which attracts the top developer talent in the short term and the largest community of developers in the long term will in my opinion grow the fastest provided the incentives and marketing are right.

[luckybit]

http://bytemaster.bitshares.org/article/2014/12/24/Introducing-BitShares-Object-Graph/

This is excellent and of bigger importance than most people realize.

[Thom]

Wow! What a monster load of info to process!!!

This is where my extensive relational DB skills are more of a hindrance than an asset, as the NoSQL model is so radically different. I read the MondoDB page you referred to and downloaded the whitepaper which I will read in the next couple of days.

I've been wondering what the "graph" terminology in bitShares "key-graph" was, now I understand it's root.

At an intuitive level I can see how the NoSQL graph DB model is a perfect fit for blockchain applications, but it also raises concerns b/c of how cloud computing is involved.

Cloud based apps & storage today is the exact opposite of decentralization, moving control of my data away from local resources to centralized resources controlled by the likes of google or other huge server farm companies.

Now that I've been introduced to the concept of NoSQL databases, I can see that centralized view of the cloud isn't necessarily accurate, as "the cloud" could be implemented as a heavily distributed system of NoSQL database servers with diverse ownership so one company may not in fact be able to control the data. To what extent a company like google has full control over all of the servers of such a distributed NoSQL model I don't know (I do have concerns about that however).

What I DO know is if my data is stored in the cloud I have less control over it than if it's on my local hard drive. This of course doesn't address the opportunity costs for capabilities I'd miss out on by sequestering my data locally.

Its really interesting to think about the NoSQL graph model. Coupling that to the blockchain in many respects is just an extension of that model, the primary difference is that it uses cryptography and peer to peer technology to perform distribution / replication in a highly secure manor.

Absolutely Awesome! Genius!

[charleshoskinson]

I also remember you spent a lot of time thinking about DHTs.  It's a shame we never had a convo about graph theory. We probably could have designed something cool.

[bytemaster]

lol, I recall mentioning graph DB here some time ago. Good work dan

Yes charles maybe everything you wanted in a coin was right here all along

To be fair I was working with graph databases prior to starting bitshares. 

[jsidhu]

lol, I recall mentioning graph DB here some time ago. Good work dan

Yes charles maybe everything you wanted in a coin was right here all along

[nomoreheroes7]

This is the most confusing exciting news I've heard all week.

Better than ethereum is enough for me.

 

[toast]

The primitive is only "object". Edges are not any more special than other "special" objects like accounts, assets, auctions, sites, etc - they just have some extra validation.

Looking through the code I see there is a clear distinction between an actual edge (in the graph sense) implemented with bts::blockchain::edge_record type, which has from and to fields, and the concept of the edge_object discussed in this thread and in bytemaster's blog post, implemented with the bts::blockchain:object_record type, which has the actual data and the _owners field or a pointer to use the _owners of another object (which I presume points to the source node of the "edge").

My question is if in the original graph example I gave in this thread the E1 "edge" would be represented as object_record with obj_type == edge_object and two edge_records (one from N1 to E1 and the other from E1 to N2), or would there be a single edge_record going from N1 to N2 that somehow gets associated with an object_record with obj_type == edge_object.

If it is the former, can we just use regular graph terminology and call the "edges" in the BitShares Object Graph special vertices (perhaps named edge_objects). In which case, the actual edges (in graph terminology) would have no information associated with them other than the from and to fields (no weights for example). It would also not make any sense to have these edges go directly from a vertex where obj_type != edge_object to a vertex where obj_type != edge_object. The edge_objects would be special from all other vertices in the graph in the sense that they have particular validation semantics and can only have one outgoing edge (assuming you guys decide to not allow an "edge" be the source of an "edge" as bytemaster suggested because of the non-constant time validation consequence).

Or you know, stop trying to make edges point to other edges (unless there is a good reason for this feature), and build the graph database the traditional way...

There is "object_record" and all other object types are an object stored in the object record (data field).
Some objects are special and require extra validation. Edges are not more special than accounts or assets - they need extra validation which is why we don't just make edges into vanilla user objects with no data.  edit: eventually and ideally the only special object will be type "script" and its special validation is "try to run the script".

E1 "edge" would be represented as object_record with obj_type == edge_object and two edge_records (one from N1 to E1 and the other from E1 to N2), or would there be a single edge_record going from N1 to N2 that somehow gets associated with an object_record with obj_type == edge_object.

Neither, there is a single object_record whose type is edge_object and whose data is E1. Making "edges" not be allowed to come "from" edges adds validation logic. That's fine because we're switching over the object type anyway, but it's not somehow more natural or simple.

[charleshoskinson]

lol, I recall mentioning graph DB here some time ago. Good work dan

[arhag]

The primitive is only "object". Edges are not any more special than other "special" objects like accounts, assets, auctions, sites, etc - they just have some extra validation.

Looking through the code I see there is a clear distinction between an actual edge (in the graph sense) implemented with bts::blockchain::edge_record type, which has from and to fields, and the concept of the edge_object discussed in this thread and in bytemaster's blog post, implemented with the bts::blockchain:object_record type, which has the actual data and the _owners field or a pointer to use the _owners of another object (which I presume points to the source node of the "edge").

My question is if in the original graph example I gave in this thread the E1 "edge" would be represented as object_record with obj_type == edge_object and two edge_records (one from N1 to E1 and the other from E1 to N2), or would there be a single edge_record going from N1 to N2 that somehow gets associated with an object_record with obj_type == edge_object.

If it is the former, can we just use regular graph terminology and call the "edges" in the BitShares Object Graph special vertices (perhaps named edge_objects). In which case, the actual edges (in graph terminology) would have no information associated with them other than the from and to fields (no weights for example). It would also not make any sense to have these edges go directly from a vertex where obj_type != edge_object to a vertex where obj_type != edge_object. The edge_objects would be special from all other vertices in the graph in the sense that they have particular validation semantics and can only have one outgoing edge (assuming you guys decide to not allow an "edge" be the source of an "edge" as bytemaster suggested because of the non-constant time validation consequence).

Or you know, stop trying to make edges point to other edges (unless there is a good reason for this feature), and build the graph database the traditional way...

[bobmaloney]

Can somebody offer the less technical of us a quick explanation of the importance and functionality of object graphs?

Thanks.

*Edit: Overlooked OP

http://bytemaster.bitshares.org/article/2014/12/24/Introducing-BitShares-Object-Graph/

[Pheonike]

What are the scaling limitations if any?

[toast]

It's not necessary and maybe not useful, but we're not going to add complexity to remove a feature =)

So it seems like the primitives in the BitShares Object Graph are node and edge objects which are very similar to one another (both can have arbitrary JSON associated) with the following important differences:

• The edge object needs a source object (perhaps only restricted to node objects, TBD) and a destination object while the node object does not have those things.
• The node object has an ACL (multisig owners and multisig updaters) defined on it while the edge object does not. These permissions are the source that propagate the ACL to the edges spreading out from the node.

And edge cannot be a source Vertex only a destination vertex. 

If that is the case, you should fix the following statement in your blog post.

This means that you can construct an edge from a node to an edge or from an edge to an edge.

The primitive is only "object". Edges are not any more special than other "special" objects like accounts, assets, auctions, sites, etc - they just have some extra validation.

[Crossover]

can you explain, graph data will be stored on blockchain, this mean that if some of delegate servers go down nothing will be missed?