I should also add a "standard disclaimer": much of what I say below could be done with any distributed database: just write some specs on how to use it, and you're done, right? The hard part is, of course, inventing an API that people won't puke on, and then convincing everyone to use it.
--linas On Sun, Feb 18, 2018 at 3:22 PM, Linas Vepstas <[email protected]> wrote: > On Sun, Feb 18, 2018 at 1:53 PM, 'Nil Geisweiller' via opencog > <[email protected]> wrote: >> On 02/18/2018 09:38 PM, Linas Vepstas wrote: >>> >>> yet more. In a certain sense, versioning and provenance is already >>> built into the atomspace, in a "strong" way. But no one uses it. >> >> >> I'm not sure I understand, could you elaborate? I can think of TimeLink, >> HypotheticalLink, ContextLink and such, is that what you have in mind? > > Well, we do not have a wiki page that explains "here's how you do versioning" > But we do have the ability to create chains of arbitrary depth: > > OrderedLink > Concept "Commit 43" > SomeAtom > OrderedLink > Concept "Commit 42" > OtherAtom > OrderedLink > Concept "Commit 41" > MoreAtom > OrderedLink > .... > Concept "root of chain" > > Due to the design of the atomspace, it is impossible to change "MoreAtom" > unless you first delete the entire incoming set. Its even weakly > cryptographically secure, in that the atom hash of the top-most ordered > link includes the hashes of every atom under it. Its not a crypto-strong > hash; its just a plain-old hash, but its still a hash. > > You could make this robust, by writing a wiki page that states that e.g. > the string "commit 43" should instead be a SHA-256 hash of everything > that came before. The wiki page could also state (for example) that a > TimeLink should be slotted in there. Perhaps truth values could be > "frozen" by turning them into NumberNodes, and wrapping each level > in a ContextLink. > > Obviously, branching is trivial; merging requires a wiki page stating how > merges are done; it does not require new software. This gets you up to > the level of git, in terms of features. (abstractly; it would take tooling to > make it as usable as git). > > If you had some proof-of-whatever, you could staple it to this, thus > creating a chain whose incoming set could never be altered because, > just like in bitcoin, it was too deep. > > So in principle, the atomspace has all the basic ingredients needed to > support a blockchain. In practice, you'd have to write the wiki pages, > create some RFP process, create a bunch of tooling, get worried > about performance, usability, etc. > > There is a to-do item from singularity.net to write smart contracts in > atomese. > > The point of this email is that you do not need to invent a new, different > blockchain, other than the one already provided by the atomspace. > Exactly what it would take to make it portable and popular, I don't know. > Perhaps I'm being naive. But it seems plausible, to me. > > (Crying over spilled milk: the atomspace was one of the first graph > databases, ever, back in the day. Now, its not even a footnote, in the > history of such things, and that's kind of the statement about a failure > to build an open-source community around it. We're now in a similar > situation, but in a different way.) > > --linas > > -- > cassette tapes - analog TV - film cameras - you -- cassette tapes - analog TV - film cameras - you -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35A1ED4%2BTNLkgFqtmVzeqRna_DjD_rm4zTpCxKcr2tyRQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
