Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Brian Platz & Flip Filipowski: FlureeDB – A Scalable Blockchain-Based Graph Database

Episode Date: January 3, 2018

Blockchain technologies are changing the way we think about data archival and storage. For instance, most database systems can only capture the current state of a data set. This means we must rely on secondary backup systems to ensure historical data can remain accessible, a stark contrast from what the most basic of blockchains provide out of the box. Database systems that offer immutability and historical context for data would be greatly beneficial for companies as it would make internal and external audits much less costly and time-intensive. We’re delighted to bring you an interview with Flip Filipowski and Brian Platz. Flip is a veteran entrepreneur whose career spans 50 years, having worked for and founded some of the world’s largest software companies of the 80’s and 90’s. He is also the CEO of SilkRoad Equity and a Founding Partner of Tally Capital. Brian’s background includes having founded A List Appart in 1994, which is among the oldest and most influential web development blogs, and SilkRoad Technologies. Flip and Brian join us to talk about their new company, Fluree. Their product, FlureeDB, is a scalable graph database which provides the benefits of blockchain technologies, such as immutability, replayability and fault tolerance. Currently, in development, the goal for FlureeDB is to support various consensus rules based on the network configuration: private systems, federated (or consortium) clusters, and fully decentralized public networks. Topics covered in this episode: Flip and Brian’s respective backgrounds and entrepreneurial ventures How blockchain will disrupt most major companies that exist today FlureeDB and the problem it is trying to solve How FlureeDB improves compliance procedures for enterprise How FlureeDB can address some of the challenges ahead with regards to GDPR FlureeDB’s technical infrastructure and elementary components The different consensus modes and scalability properties of FlureeDB Why they chose to structure the company as a Public Benefit Corporation FlureeDB’s development roadmap Episode links: Fluree Website FlureeDB Whitepaper Blockchain, Meet Database This episode is hosted by Sébastien Couture. Show notes and listening options: epicenter.tv/216

This is Epicenter, episode 216 with guests, Brian Plotz, and Flip Philipowski. Hi, welcome to Epicenter, the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Sebastian Quichu, and today I'm once again doing the show by myself. Brian and Mayor were not available, so I'll be here today, and I'm very pleased and very honored to bring you our two guests today. Flip Philipowski and Brian Plotz. And those are names that you may recognize because they over the years sort of operated in and around the periphery of the blockchain space.

Flip is one of the co-founders and partners of Silicon Road Equity and Tally Capital. And previously, because Flip has a very long track record of building companies in the technology space was chief operating officer of Cullinette, which was a company that was one of the largest software companies in the 1980s. And after that in 1990s, the founder of Platinum Technologies, which was also one of the largest software companies

at that time, which in the late 90s sold for many billions of dollars to computer associates. And so we're very pleased to have Flipon to talk about his experience in the software space and specifically with regards to selling to Enterprise. And Brian is the co-founder and COO of Silgrove Technologies and previously was co-founder of Elis Apart. So for those of you who come from the web development space like myself, we'll be very familiar with Elista Part as a sort of a great resource for web development and web developers in general. looking to expand our knowledge about web devs technologies and that blog still exists now. And today they're both here to talk about their new project called FlurryDB.

And FloryDB is a blockchain technology stack that caters to enterprise and that specifically allows for decentralized distributed databases that also have the benefits of blockchain technology in terms of immunability, permissioning, and all these great features that we often talk about. So we're very happy to have you both on today. So thank you for coming on and look forward to the discussion. You're welcome. Yeah, thank you.

Glad to be here. So, I mean, we could spend this entire episode as sort of a how to, like building software for enterprise. Like we could just spend an hour on that topic. Unfortunately, well, fortunately, there's also, Floree to be to talk about. But I do want to spend some time brain picking, I suggest, I suppose, and talk about your respective experiences and what you've learned over the years and how companies today in this space can leverage these lessons from the past, right?

Because a lot of the things that we see happening in the blockchain space today in terms of technology adoption and sort of hype adoption curve and all these things happened before. We've seen them before and people that were around in the 80s and 90s and probably looking at all these young entrepreneurs and going, like, what of these mistakes they're making? But first, please, I would like to both get your, perhaps starting with flip, respective backgrounds, and how you got to be interested in blockchain. I guess we could do some time traveling on this question. but my background spans about the last 50 years. In 1970, actually 1967, I began my career with Time Incorporated. So I'm not going to go all the way back through that.

It would take up the entire session here. But I am going to say that my particular background has always been in the enterprise space. I had a very substantial role to play in the development of database management systems before relational database systems were in play. Cullinette was the purveyor of IDMS, a Codacil standard database management system that replaced earlier technologies that I worked on.

Some of them became DB2 for IBM. They became relational database systems. Some of them died out. Some of them linger on a long tail, but I think I've been connected to most of the database technologies that have been developed over the last 50 years. I truly believe that blockchain is a very special thing. And those that recognize the Internet for what it was benefited enormously. Yes, they participated in a bubble that did have its negative consequences. for some businesses that were not ideally positioned,

but for companies like Amazon, who we today recognize as a giant in so many different disciplines. If it wasn't for the Internet, they could not possibly exist. Neither without the smartphone could we have an Uber or an Airbnb. Those are all things that are done on the basis, or were done on the basis of recognizing some very special technology that could be utilized. Blockchain is that kind of thing, maybe even a 10x, that kind of a thing. I think it will lead to decentralized organizations being able to exist.

I think software, yes, will devour this world, and it will be on the back of blockchain that many of the new enterprises, some without any employees, will be. able to develop software that will contribute to the benefit of all mankind. That's a tall order, but I believe blockchain has that ability. Yes, that's a point of view that I definitely share. Taking from your experience and how companies have been able to navigate the changes that have occurred over the last 40 years, right, or maybe even 50 years, right, starting with, mainframe computers and databases and then the internet and then like the

worldwide web that we know now and mobile what kind of things can we what lessons can we pull from from from all the what are the commonalities I guess between all of these changes that you have seen that we should also apply to blockchain and that industry and enterprise companies should also look to as sort of a guiding light on how they should look at blockchain? Well, blockchain is this remarkable thing that I believe will be deployed in manners that we have not yet imagined. In other words, we're very early in the way that blockchain will be utilized. Unfortunately, for most companies that exist today that are struggling to understand blockchain,

just because this is the way the world seems to work. When new, brand new technologies get delivered, and people recognize them, a whole new host of successful businesses is formed around that concept. The old companies tend not to survive. In other words, there's a mortality rate of probably greater than 99%. So yes, all the current banks, all the current insurance companies, you name it, are all interested in deploying blockchain, but ultimately they will die because of blockchain. They won't move fast enough, they won't adopt, they won't change, they won't eat their young,

and all of the things that have happened every time one of these new technologies has arrived will happen again. I call attention to the fact that 10 years ago, well now it may be 10 years and 6 months ago, Nobody knew what a smartphone was. And then in July of 1997, I'm sorry, July of 2007, Apple introduced the iPhone

with all kinds of hopes that it would have an impact, little understanding that one day, almost everybody on the planet would know how to use it in a short period of time of 10 years. And I think that's, again, the signal that everyone should have is if you don't move at breakneck speed, you are probably going to die because as an organization, you weren't built around the technology that will drive the future.

So that's my contribution to that or that answer to that question. No, that's a great answer. And again, if we are to look back at how companies have adapted or failed to adapt to new technologies, I look at say the content industry, the film industry, the music industry, you know, that we can point at specific successes and failures there. You know, e-commerce and retail. You know, I came here to France about 10 years ago just as e-commerce was booming. And I mean, we can clearly look at like sort of incumbent companies that had been there, like the sort of Sears or, you know, are like these retail stores that failed and like disappeared in the matter of a few years, but others that.

got through it. What would you point to as good strategies for adopting this technology rather than looking at it as a threat or like how can an existing company like a bank or an insurance company have some glimmer of hope that they will be around in 10 years? I don't really think there is a glimmer of hope, but let's just say there is for the sake of of the audience that is going to be listening to this. I know how much trouble I got into by predicting that Sears would be missing from that list of major retailers in a short order. I was probably a little bit optimistic.

They'd be gone sooner, but they are, for all practical purposes, Kmart, and for all practical purposes, Sears doesn't exist, and frankly, in the short order, it won't anyway. So what is the secret to succeeding? The secret is to create a side business and pour all the resources you possibly can into exploiting the newest technology. So, for example, is anyone responding from traditional taxi cabs and transportation businesses

to the Uber threat? Is anybody in the hotel business responding effectively to the Airbnb threat? Frankly, Uber. and Airbnb have to worry about blockchain because with the deployment of blockchain, they will be decentralized anyway. They will be made irrelevant in the context of the next generation of Uber and Airbnb, which will have no employees, and simply rerun on the software that can be downloaded

by those contributing autonomous vehicles, as well as those that are picking up passengers. passengers. So there'll be certain applications that once you load them up, the only thing visible about an Uber and the only visible thing about Airbnb will be the fact that it is software and it will probably have a lot of AI characteristics, but it will definitely build on blockchain. So I don't know if there's a successful strategy other than being very destructive of your existing business by pouring all the resources into the next opportunity. And because that's such a difficult thing to do in business, most people just won't do it. They'll play with it. They'll cover their butt with it. They'll act like they're doing something, but they really won't be because they just can't sacrifice the existing business to this new technology. That makes a whole lot of sense to me. Again, coming from the sort of commerce and

e-commerce side, you know, before previously to being in blockchain, I think the companies that, you know, the few companies that were somewhat successful that managed to hold on to some sort of market share were the ones that invested in like other startups. And frankly, I mean, restructured the existing business, you know, huge job losses, like revenues down on those, on that side, but, you know, are seeing some success in these smaller, more. more agile, niche businesses that they were able to sprout as a means to adopt this new technology, which was e-commerce 10 years ago. Fascinating. I mean, I could ask you questions all day. But just to switch over to Brian, I'd love to hear about your respective backgrounds.

As I mentioned earlier, as a young web developer, like in the late 90s and early 2000s, learning to code. and do HTML and CSS. Like, Elista part was one of my main resources for, for learning all the hot new things going on, and the CSS hacks, and, like, I learned an awful lot about UX.

So you and Jeffrey Zeldman did a great job there and really benefited to that whole community. And, of course, Elista part is still around. And I don't read it so much anymore because I don't code. But I do see articles come up once in a while, and it's always great to see it there. So, yeah,

Please tell us about your journey in this space, starting in the 90s and now how you've got into blockchain. Sure, yeah. Well, I'll be somewhat brief about it. I started my first Internet-based company in my seventh year of college. So obviously, college wasn't something I was very good at. And luckily, I found a path through Internet. So I was involved very early on. and certainly the early days of the internet, I believe, have a lot of things in common

that we're seeing about the early days of decentralization and blockchain technologies here. But I have been involved now with six or seven different companies and starting them and being at least a core part of their origination. Most of them dealing with either enterprise software or internet-based technologies, probably one of the more influential times was that early internet era, and you bring up e-commerce, certainly developed and participated in some of the largest e-commerce sites that were ever developed, and really around that time when businesses were trying to figure out what to do. You know, they had their retailers, which they had commitments to,

They didn't want to upset. And at the same time, they needed to invest in their own web presences that would cut out the retailers to be able to sell their products. And I think blockchain and some of the things that Flip brought up have the same characteristic that these existing businesses have to be able to kind of sacrifice their existing channels. And the people that they're working with to be able to focus on more direct initiatives if they're going to survive. The last company, I've been working, Flip and I've been working together now since I think 1999, about 18 years. And the last company that we founded together

was Silk Road Technology. Silk Road grew to about 500 or so employees. And the focus there was on human resources, talent management software. It's something that both of us are still very passionate about and know quite a bit from being in the bullpen, so to speak, around that. And of course, now our focus here is on building FlurryDB. And what lessons, again, I'd like to turn the question to you now, what lessons do you think we can pull from,

from these early days of the web? And so the startups that were emerging in the late 90s and early 2000s that may be valuable for blockchain companies now and the same sort of challenges that they're facing with regards to selling to enterprise and sort of thing? You know, one thing that I see, which I think a lot of the blockchain technology companies perhaps not doing a fantastic job of, is marketing to specific customers. And I think the early days of the internet kind of had some of this as well. I think that ultimately people buy solutions that solve problems that they're having, and oftentimes even the problems that people.

describe themselves they're having aren't their real problems. You know, you kind of got to get down a level and really understand those issues provide solutions that give people to buy. There are hundreds of projects on anybody inside any enterprises plate and they're only going to be doing two or three of them in a given year maybe and the key isn't just to have a problem that hits to that top 100 list. That's actually not that hard to do and The key is, how do you get into that two or three that actually get purchase and deployed? And one of the things I do think I see a lot of the companies doing today is that they're building good infrastructure, which I think is important for longevity. So you want to have multipurpose products that are kind of horizontal, that can be flexible and nimble,

and that's going to be really critical to fend off the competition. And when you don't have that, assuming you are successful, it is crushing. It is crushing to have technology that cannot readily adapt because you're just under so much technical debt. The competition picks up. It's a very, very challenging place to be in. It's a place that I think anyone who's been in the software industry for a long time has found themselves in many times. But while building horizontal kind of enabling technology is important. in the early days, being able to market it to specific pain points and problems is the thing that's going to give you the chance to survive

where the competition actually wants to, you know, kill you and get ahead of you. So both are important. I see a lot of kind of horizontal focus messaging right now, and I think some of that needs to get a little bit more laser focused for people to get to the next round of the fight. That's interesting. This is something that I've been thinking a lot about in sort of my own business is this balance between spending a lot of resources on building the infrastructure and the resources that you spend going after specific problems and trying to solve them with like a niche product. And one of the things that I've seen happen that we've seen happen in the last few months, I guess, sort of accelerate in last few months is seemingly a sort of homogenization. of the enterprise stacks, the different enterprise stacks that exist. And the infrastructure layer, you know, from one company to another,

effectively selling to very similar verticals is, you know, clearly, I mean, is getting to be indistinguishable. What are your thoughts on this? And how do you think companies can differentiate themselves from others when, in fact, their infrastructure, although the technologies may be different. the implementation may be different. The features, the feature sets are very similar effectively. Yeah, I think a lot of this comes down to sales and marketing, which a lot of these companies are going to have to get very good at to survive. You know, everything from thinking about

verticalized sales forces to just how you're positioning your problem, how you're getting into markets through channels. All of these are, you know, there's sort of a stew of strategies and you've got to kind of pour the perfect cup of the right ones to execute at the right time. And of course every industry is going to be a little bit different. I think if you think about kind of the, I guess a major force in particular business software is, of course, the traditional ERP vendors, the SAPs, the oracles, they all had a similar stack. And one of the things that you saw them doing is verticalizing tremendously. I mean, they have vertical blueprints for, in manufacturing or a specific segment in manufacturing.

This is exactly how you stitch together all these technologies to solve your very specific problems. And a lot of that ends up, the differentiator around that becomes some of this sort of content marketing and some of the sales, but a lot of it's the services. It's the people that are wrapping together these specific solutions out of these general technologies. fascinating we could spend the entire episode and more talking just about this but let's let's talk about

what we came here to discuss and that's flurry db this is something that came across my radar very very recently and i read the white paper and thought it was very interesting and i really appreciated the architecture and the way that you're implementing this technology so please tell us what is FlurryDB and what problems does it address specifically in the markets that you're targeting? Sure. So FlurryDB is a database that at the core of the database sits blockchain technology. So if you look at any database that really you've ever used at their core is really records management and indexes. That's kind of the aspects that power every database. And then there's layers on top of it. layers that enable easy querying, there's layers that enable security, there's layers that

enable all of these sorts of things. And FlurryDB is similar, except at the core, is blockchain. And then we have layers built around that to support querying and to take advantage of it. Or take advantage of some of the unique characteristics it has. One of the reasons that we felt this was an important project is that we think blockchain technology, obviously is important and can solve a lot of business problems, but we think it's pretty inaccessible to practitioners today trying to solve those problems. There's a lot of niche solutions out there, and in any case, even if you can solve a specific problem that you're having using the technology, it requires you to add a completely new component into your technology stack.

And a database is a very natural place to have, I think, blockchain characteristics in. And in addition, every single application developer who's ever developed anything has used a database. They understand it, they know how it works. So fundamentally, they don't have to figure out how to kind of pull in this new component and how it fits into everything

and bolting it into everything else that they're using. They can actually just use a database and get some of these characteristics for free. So one of the, I guess, key messages we have for Flurry DP is that it's making blockchain capabilities accessible for everyday developers. And addressing, I think, some of the challenges and the inaccessibility that current solutions, I think, have. So how would you position Flurry then in the context of the existing blockchain technology stacks that are being sold to Enterprise today? and how is it different from, say, other, I guess, similar stacks like Big ChainDB that try to take this database, or I guess they try to blockchainify database is one way to put it?

Well, I think if you're trying to leverage blockchain technology in an enterprise application, If you have a very specific use case that an existing technology, like an Ethereum perhaps, can uniquely solve, then that's great. You can go to Ethereum, you can build the smart contract or whatever it is you're trying to accomplish and pull it in. I think the use cases for that, at least what we've seen the use cases, end up being pretty narrow. So there's a lot of ideas, a lot of experimentation, just not a lot going into pretty narrow. production at the moment, a lot of enterprise applications need to rely on simple things like storing data and immutability aspects of blockchain are tremendous. But for example, just using Ethereum, and if you were trying to store, say, supply chain

data in there and you came up with a gigabyte of data amongst your supply chain partners that you were trying to put, and a gigabyte of data isn't that much data. So right now, based on, or actually as of a couple weeks ago, I don't know what it would be now, based on the current gas price, it would cost about $5 million U.S. dollars to store a gigabyte of data on the Ethereum blockchain. So obviously if you need to store data related to your supply chain, you need to store it somewhere else, and maybe there's a sliver of it that you're recording onto Ethereum because that's all that's practical. And by contrast storing a gigabyte of data on Amazon Web Services, in S3 for example, I think it's about 2.3 cents. So making that technology practical, I think, is the core of what we're trying to accomplish.

And that's just one example. And I think the other areas where existing blockchain technology, there's sort of this tradeoff between very public, being the public blockchains, very expensive and very slow. And I don't know that everyone always appreciates the cost of consensus. It's actually very expensive, both in terms of transaction time and money. You know, Bitcoin obviously taking 10 minutes to confirm transactions, Ethereum even 15 seconds. There's a cost in there that takes it out of the practicality for a large number of applications. And then we have kind of private blockchains, which perhaps have some advantage.

on speed, but then there's other sort of trade-offs. And another thing we really wanted to address with FlurryDB is allow you to take your application data and know that some of it probably does want full public consensus and that's going to come at a cost, which is fine. Some of it can sit internally and be private and some of it might be shared amongst organizations. Why shouldn't you be able to have all those characteristics

in a single system? And FlurryDB aims to address this. We call this concept hybrid consensus. But the idea that you can actually align the data with the consensus needs that the data requires and not try and put all your data in a public blockchain at a massive cost when not all of it needs to be there. Only little parts of it need to be there. I do agree with you 100% that as these technology stacks mature, we're going to see a segmentation of the different blockchain stacks, and they will interoperate.

I mean, we're already starting to see this, but it does make a lot of sense to say that there's something like Ethereum has the ability to perform transactions at a cost, right? And those transactions are of a specific nature and mostly related to putting some kind of business logic execution in a blockchain and the blockchain recording the state of that. But if you want to store, on the other hand, like massive amounts of data in an immutable way that's sort of compliant with regulation and like GDPR and this sort of thing,

you're going to need something different from that. But that's very similar to a way that we build, you know, traditional web applications today. You know, you've got your Ruby development stack and then you've got, and within that, you have the different layers for data, for APIs, for the business logic itself. and I feel that we're going in this direction in blockchain as well,

and anybody who fails to see that just needs to look at, look around you and look at the way that we build web applications today. I mean, it wouldn't make sense to do it otherwise. So then if, from what I understand of reading the white paper and looking through your website, FloryDB is a stack of technologies that incorporates all these notions that we know about blockchain, so that's like immutability, the ability to record the state of data in time, access controls, these sorts of things. But does it in a way that where you can

store significance amounts of data in a no-SQL format? Can you expand on some of the technical aspects of FlurryDB? Yeah, and I guess the first part is that I wouldn't consider it a no SQL. In fact, it's much more of a graph database. Okay. And it's a graph database that actually supports acid transactions, which if anyone's built, you know, enterprise applications, they realize how important that characteristic is. So it differs in this way from a MongoDB or a rethink DB or Big Chain DB, which you brought up, which is also built on these NoSQL things. So the idea that you need to perform atomic transactions,

across various tables simultaneously, they either all succeed or fail, is a pretty important characteristics that much enterprise application relies on, certainly not all of it. And I guess one of our main goals of this is that we had to be, at least in our opinion, the best database out there for people to adopt this technology. And the idea that blockchain can exist in everything we do, just like, you know, we draw parallels back to early days of the internet, and there were a lot of companies that started out that were trying to do

internet something, and, you know, internet is now in everything. It's just a feature. And blockchain, I believe, should also have that same quality. Everything that we develop, and it might not be this year or next year, but everything that we develop will have this feature set in it. So one of the things that we went about doing is we were, kind of reinventing the database. We thought a graph database is a great format,

sort of offers some above and beyond capabilities over a relational database. But since we are actually storing a full immutable history of all changes to that database, what else can we do to really leverage that characteristic? And so one of the things we've built in is this concept of time travel, point in time queries. So every single query you issue to the database,

you can issue as of any block in history or any wall clock time you can use. Any point in history, the identical query, and you will get an instantaneous result. So you can't do this probably with any database that you're used to seeing. They always only answer, as of right now, here is the answer of that question. You can't say, what's the answer to this question a year ago without going to a backup tape and restoring the database if you still have it as of a year ago. that is. As I was reading the white paper, I was thinking, like, this is so, this is insane that like no database stack that we use today, like SQL or new SQL or Mongo or whatever,

have this capability built in. It seems like something that would be, like, you have this, you have this in like, you know, pages on, you know, your Mac, right? For like Word documents. Why wouldn't you have this in databases? Well, doing it and doing it at scale is not necessarily a simple thing. So that's definitely one aspect. and I'll let Flip talk about sort of the constraints that existed when the databases that were just sort of used to and accept today were created, they had much different constraints than we have today. I mean, that is exactly the point.

The word constraints fits. When those relational databases were built, they were built with the knowledge that the current technology, everything from the cost of disk space to the cost of CPU process, that the cost of processing had a certain limitation on the deployment that they could make. Today, those constraints for the most part have disappeared. The reason why the oracles and other SQL-based systems are vulnerable is because they're dragging along a user base from the 70s. They have all of that baggage to support, and they cannot abandon the theories that they were, that they used in order to create the product in the first place, those being you have to conserve this, that, and the other.

Their logging mechanism was created not in an era in which disk was cheap. It was created in a era where disk was very expensive. And they really can't dramatically change that. They can't backfill in with blockchain. They can't add these features and simplify the the way that you can if you're starting from scratch, knowing what the technology constraints of today are. And I think that answers pretty much the question of why there is little hope that the existing technologies will be able to move into the new era with immutability, with time travel, all just basic features of technology that we use to store data.

When you have some of these new capabilities, too, it's a... It's amazing, certainly I have and other people have used this, you start to change how you develop things. For one, there's a certain comfort knowing that you have everything that ever happened, right? You don't have to worry about like data just disappearing or losing some update or something like that. But with enterprise systems, you're constantly dealing with issues like backup processes, you know, that run at midnight and they take a half hour to run. And the whole time, the data is changing underneath the database,

and lots of times things fail because the relationships that existed at midnight are different than the relationships that existed at 1215. Well, if you could grab the database and treat it essentially like a variable that you have as of a specific point in time, you can, when you wake up at 8 a.m. in the morning and you realize that something didn't run successfully, you can actually examine the database in that identical state at that point in time and figure out what happened. Or when a customer calls and said, hey, you know, this price on this product, I swear, said something different an hour ago.

And, you know, the support rep looks at it and says, I don't know, you know, it says the right price now. Well, of course, there might have been a number of changes. No one can track that. And all of a sudden you have the ability to better support customers. There's just all sorts of things that you can start to approach differently. We built a specific application, which we could talk about later, a cap table application that really leverages this. Let's dive right into that. Sure.

It was a good example application. For one, we wanted to build some applications that leveraged our database that we could go out and get customers using on a production scale. So we could test out the technology and performance characteristics and, of course, start tweaking it. And one of the applications we decided to build was something that manages a corporate capitalization table. And this is something through years.

We have seen startups try to manage this on spreadsheets. Different people have different versions. someone thought they had 1.37% based on something they were told in February, and now they're getting something and says they have 1.36%. And what changes? I mean, this is constant. So the idea that you could build an application and put zero additional effort into a feature set that would allow you to rewind history to any point in time and get an instantation,

response was a pretty powerful concept. And from an application developer standpoint, they had to do zero extra to introduce this capability. So one of the things we put in the UI was just a clock in the upper right hand corner where you can go set that clock to any point in time in history and actually use the entire application as that application existed

at that point in time. And if anyone's tried to log out history when they've developed an application, they know it's a lot of effort. First you need to decide upfront what you're gonna be tracking history of. You end up creating a totally separate set of tables to track that data. The relationships that data had, oftentimes you're not also tracking, so you don't know the relationships that existed at these different points in time.

It's a massive effort. And this was really a really useful use case, but something we were able to create that added quite literally zero additional effort from the developer standpoint to have this sort of capability. pretty powerful concept. Very interesting. I can definitely see how, you know, if you, indeed, if you have this technology stack that you can just plug into your existing application and, you know, sort of reap the benefits of this, this idea of time travel.

And we'll get into the sort of technical aspects in a second here, but if you could plug that in and you have all those benefits and you have the immutability and you have all the compliance and all that stuff, then there's, there's no reason not to just use this instead of something like a graph database that you would typically use. So let's spend some time then on the technical infrastructure and some of the elementary components of FlurryDB. One design decision that we made is that we wanted this database to be able to scale and be extraordinarily fast.

And so part of the challenge of that comes with consensus. And consensus, you know, even if you're getting down to five-sexuals, consensus times on a public blockchain, from a database standpoint, that is extraordinarily slow. So certain data aligns well with that. You know, if you're used to trying to settle a stock trade and that takes three days to settle, and you can settle that in five seconds, that's pretty fast for that. But for a database, maybe, you know, doing something that has, or any application that has any type of real-time characteristic, that is way, way too slow. And there's certain physics that get involved.

I mean, I think that we will see kind of these consensus or block times and a lot of blockchains continue to decrease, but there's going to be a certain limit that they are going to have a hard time getting over. I don't know what that is. I suspect it's going to be a few seconds. It's going to be a real challenge for any blockchain to get beyond, assuming they have broad global consensus taking place.

But we'll see what happens there. So one of the design characteristics we decided to do was what if we could segment our data to leverage different consensus modes to take advantage of the privacy and speed where we need privacy and speed and the transparency which comes at a cost where we need and are willing to pay that

for that transparency and cost. But if from an application standpoint, if you could treat that, even though these different segments of data is as though they're one single database, the applications you're developing can remain extremely simple. They're just talking to a single database.

The database itself and where that data comes from is coming from different consensus modes. And so this kind of brought us into the realm of actually doing a graph database joins essentially across different databases or segments and treating them as a single database. So that was certainly one aspect. of what we're looking to do.

The other is that we, when you're building blocks, you really require a notion of a, kind of a single threaded transactor. Something always has to know the state of the database at a given time, and you can't necessarily do that in a fully distributed way. And certainly, blockchain or all these other, or Bitcoin and all the other blockchains don't do that,

Of course, they're distributing consensus, but only one node is developing that at a given time, and they're working from the truth that they understand. So what we did is we actually built the query engines as a separate layer, which you can scale, you can run a thousand query engines or however many your application needs for performance characteristics.

And it's the query engines that you're actually issuing your application queries into, and they will relay transaction data to your sort of single, transactor for your database. So that's another important characteristic of how we look to scale this. Interesting. So at the moment, looking at your website, it looks like there are multiple stages of how this will be deployed. So currently, I think you're at the stage where one can deploy this sort of internally and have all these features that we mentioned.

And then further down the road at some point, we'll have the ability to deploy this as a federated sort of consortium blockchain, say for like a consortium of insurance companies or banks or something like that. And then in the future, further down the line, I think the idea is to have like a public network, that one can use with any type of application. Talk about the different, because, I mean, you know,

all of these deployments would require different types of consensus, right? If you've got a fully distributed network that requires some kind of consensus, you're presuming that the validators are anonymous or synonymous, and if you have a more federated model, then that requires a totally different type of consensus,

Have you given any thought yet about what this is going to look like as you deploy these different, I guess, types of stacks for these specific types of use cases? Sure, yeah. And I think each of the use cases leans towards a different model that makes sense. So the idea is that we will support multiple consensus models. and you can choose to use something that more aligns with the needs around a fully decentralized public consensus model. You can use that internally if you want, but in many cases it doesn't make sense. So around a federated model, what we see a typical requirement being is a group of 10, 20, 30, 50, 100, whatever it is, companies, deciding that they are going to run a database decentralized, but amongst them,

themselves. And in that scenario, essentially, there is a process to determine who's going to be invited into that. They have the equivalent of an account, essentially, on the database, which they can authenticate and participate in. And consensus will most simply be driven in that model by some percentage of essentially validation around transactions that happen. So it might be that, you know, 80% of the nodes that are invited to participate into this database have to say, yes, this transaction or this block. Like you may have a sort of tendermint style Byzantine fault-tolerant consensus, essentially, which is like a voting mechanism.

Yes. Yeah, a voting mechanism where they would approve and then, of course, whoever is producing the block or performing that particular transaction can rotate. These are all things that different business requirements we feel like will dictate. you know, different configuration options. And I guess the key there is that we want that to be configurable to meet the needs of the particular use case.

In what we call an internal mode, there's, you know, I guess one question would be is what's an internal blockchain and what benefit would that provide? And we think it provides a couple benefits. One is thinking back to this idea that you want your applications to be simple and how to be.

how they interact with the database. So if you are using a public consensus database, maybe part of it from a federal, part of your databases from a federated model, you're also as a business gonna have internal data. You have no desire to share, but our ability to connect all these databases together will end up making sense that you run one

of a blockchain transactor internally. The other benefit you get is you do get a pretty strong sense of tamper resistance from that. So a tremendous amount of money is spent on auditing, of course, with companies. And we've been doing this for years, even as a software organization, trying to comply with SAS70 or now the SSAE 16 or SSA18 compliance. We have to hire auditors. They come in and they start looking through our paperwork and our emails and make sure that we're following all the controls that we set out in our certification, which might be, you know, terminating access to systems for employees when they leave the company.

Within a certain amount of time, they might be regular performance of disaster recovery activities, whatever those controls happen to be. By having a core immutable blockchain, even though you're running it internally, provide this tamper resistance, it actually significantly eases the job of auditors, and we think it has a potential impact on that industry.

So that's sort of the internal model. We talked about the federated model, and of course the last model, and the last one we intend to fully launch would be the public model. And really the vision for this is that you can launch a database and you set up for that database

how much you are willing to pay for people to keep that database active. So that may be in terms of per megabyte hour. You would pay for that via some sort of token and you are essentially inviting miners to participate in that. And of course the more you're willing to pay, the more minors you wind up

having and again that will vary based on the needs of your application. They may be such that you want tens of thousands of miners in which case if you're willing to pay for that you should be able to easily achieve that or it may be that you only care about 10 because that's the nature of your data and that's fine too and you would end up paying far less than that and then you end up also paying obviously for transactions to be created. Our default consensus mode for that is going to be a proof of stake mode. And, you know, there's some other intricacies in there. The thing that we are exploring and that we would very much like to move towards is a concept

around proof of capacity. And of course, you know, the only coin that I'm aware of that's really doing this to some degree at scale right now is burst coin. So we're looking at some of those technologies and that's a very interesting mode of consensus for us. But right now, proof of stake is sort of the table stakes for us, but we're also exploring a couple other aspects. And they may even be configurable. And one of the things we actually want to see with this public blockchain mode is the ability for people to launch a database, for example, to store climate change data, or to store genomic data, or other sort of kind of altruistic

information, and have the ability to set a price for miners that they're willing to pay to run that database, which in those cases might be $0.00. And people will want to mine that database because they believe in climate change and they believe in storing and having permanent records of that data. So the idea that people can launch databases and set a price for it and even have global databases of sort of critical information that nobody's paying anything to mind. People just want to mind to be able to help out is something we would like to see. I agree that there's a massive benefit in having these public database infrastructure layers readily available for anyone to use. I mean, one of the close things that we have to that today would be something like the web archives, right?

That archives the web and has been for many years. And you can sort of go back and look at the version of a website from 20 years ago. you know, if a snapshot has been taken, on the other hand, you can't look at, say, API data. I mean, you can't say, like, what was the, what, what was the result of this API call five years ago or 10 years ago or even just yesterday? And I think there would be, there's a lot of benefit to having that. Now, if you can have that as, like, as a publicly available network that anybody can, can access and applications can plug into and, and send data to it and it could be stored there. Then, you know, there's all kinds of great applications for that that obviously serve the public good. I'd like to come back to that.

You mentioned compliance. And I think that obviously this is a great idea. So if you are to look at it from an internal perspective and how this type of technology facilitates the job for like an auditor that comes in and so, okay. Well, I mean, I know that I have all of the records here because the database says so, and it's sort of built in that I can time travel and go back. And I have the immutability. And I have the digital signature of those who sign those transactions. On the European side here, and we've been talking a lot lately about GDPR,

which is, of course, this general data protections regulation that will come into effect this year. And companies, like just a few months out are still struggling to figure out how they're going to be compliant with GDP. and all of its requirements. And so I'd like to get your thoughts on how GDPR or how FLORADB can address some of the requirements, like right to be forgotten, you know, consent of a user in regards to how their data is used, things like reporting requirements and that sort of thing. Yeah, sure. So we talked a little bit about this concept of time travel and having the history and how it can

impact and, I think, benefit application development. And the whole area around auditing and compliance is one right for efficiency. And I can say just our last company, Silk Road Technology, we spent almost $100,000 a year, not including our financial auditing, just for our service organization auditing. And auditors would come in on site and essentially what they would do is look through chains of emails, look through documentation, and just try to be able to demonstrate that that no one manipulated any of the information that we're ultimately providing.

And if you sort of get back to the source of that and you have a database that can prove that tamper resistance, I think it eliminates a huge amount of the work that they're basically coming in and playing detective about because you do have this source of truth that's difficult to manipulate. When we talk about the right to be forgotten, that is sort of almost as odds as it can get with the concept of a public blockchain

that never forgets data. So how can something like that be addressed? So I think there's a couple of way of having that type of data in FlurryDB if it is the type of data you wanna store there to be able to do so. One is that FlurryDB does enforce a strong schema. And it does this because essentially it needs to run autonomously.

So it has to have a lot of strong rules around it, exactly what can go where. And we also support a notion of database functions and database transaction functions that actually allow data to be manipulated within the database itself. One of the things that we have as a flag for an attribute is that you can set up data

that you're looking to store publicly is encrypted. And it takes away a couple of features. So we can't do, for example, autonomous or database functions on encrypted data very easily anyway. Like if you were trying to increment the counter by one, well, if the number is encrypted, you don't know how to increment it, for example. But leveraging encryption is a way to solve this right

to be forgotten. So if you are storing the personally identifiable information, in an encrypted manner. If you're storing a set of keys to decrypt that data separately, the right to be forgotten can be as easily as deleting the key, no longer having access to the key.

So the data is technically there, but it's garbage. Nothing can be done without the key, and therefore it is inaccessible to anyone. Another concept is leveraging our ability to actually do joins across several databases simultaneously. So if you have a unique identification,

on the public blockchain that does not have any personally identifiable information on it that can be joined with an internally run FlurryDB where you do have that personally identifiable information. We do allow when you're running, when you control consensus, we allow one specific feature to address this problem in particular, which is the ability to completely retract an entity.

Now we still store a record that that entity was retracted, who retracted it, why it was retracted, but we can actually eliminate data when you're running it internally. So by doing this join, part of the data can be public. You can't obviously ever tamper with that. It is out there. It will never go away.

But you're joining that unique identifier with the identifiable information internally, which we do give you the ability to permanently erase. Or the other option is figure out why you need to store this data on a blockchain to begin with. And, you know, it's, isn't necessary and in some cases it may not be. Great.

That's all very fascinating. I'd love to talk some more about the technical aspects. I know we could go on for very long here, but we do have to wrap up, unfortunately, in a few minutes here. Before we do, though, I would like to adjust one thing that's very interesting about this company is that you've set it up as a public benefit corporation. Flip, could you talk about why you chose this structure and what is a public benefit corporation? It is a easy thing to describe in the sense that it is a permanent charter document that says you will do these things for the public good.

And it is not easy to retract. It's an immutable characteristic of a corporation that regardless of who might acquire you, regardless of what investors you might attract, there will always be this component that you exhibit in the operation of the corporation. So you saw, I think, and heard, Brian mentioned there might be certain kinds of blockchain-based databases that are created that are really for the public good. There's also education that can be provided in order to provide folks the opportunity to redirect their activities in life after their job of being a taxi driver or their job of being in the transportation retail business is eliminated by what is no doubt going to be the case in the next five to

ten years. Many of those jobs will suffer. They may not be completely eliminated, but enough of those jobs will be eliminated. And we believe that there is a requirement for organizations to understand the impact that technology is going to have, whether it's AI or blockchain, and to do something about it in order to contribute to the well-being of everyone in the community of human beings. And we have that as part of our charter. So what are some of the things that are the specific things that your company is sort of within the Chargers says it will do? Can you point to anything specific?

Yes, I think that in a short sentence, encapsulating what it is, is to take individuals and promote entrepreneurship as well as the necessary skills required to create these autonomous organizations, the software that will be required over the next decade to be built in order to define the economy of the future. Fascinating. I think this is very needed in this space. I mean, as you mentioned,

a lot of jobs will disappear in the next five, 10, 20 years disappear or will morph will change. I think the landscape of employment will be very different in the next two decades. And if companies that are contributing to that change can somehow, make some sort of an engagement to society that they will contribute to help make that change as smooth as possible for the people that would be affected. You know, that's something that we all stand behind, I think. Yeah, it's important to understand that the nature of a human being's relationship with a

corporation is going to change. And that many, many years ago, a model taken out of the Civil War military, complex is the current model that we have in our current corporations on how we relate to the subservient role of an employee. And I think that's going to change. It's going to change many, many different ways. But one of them will be is that there will be a peer relationship between organizations and the contributors to that organization, the contractors that may on an open source basis or in some other way provide the technology that drives the businesses successfully. All of that has to be rethought and we hope that in

addition to providing the stack of tools for this that we will also somewhat alleviate the complex problems of unemployment that will result as a result of these various technologies being available and the I guess the Moore's law of them reach singularity in the not too distant future. Well, it's a very noble cause. So before we wrap up here, can we get some insights about the development roadmap, where are we currently? I mean, I know you mentioned all these different steps in deployment, the federated model, the public network. Can you give us some kind of timeline here?

And also, there's one thing that should be said is that currently, Florida DB is not open source. Why is that? And do you plan to open source it sometime in the future? Yeah, sure. So on the open source question, absolutely, we plan to open source it. It is, you know, in the fairly early stages, we have been working on this technology now for three years. And our first major milestone was earlier this year actually building and deploying enterprise applications that are leveraging our technology.

We're of course, we're the primary user of the technology, but we're able to prove it out, and that has gone extraordinarily well. So as of about a month and a half ago, we opened up the technology to beta users, and we are in the process right now working with several organizations, software companies, primarily, who are looking to use FlurryDB to back their applications and bring these concepts of immutability and blockchain. to them and some of the benefits that they provide. And really our next milestone after that will be to lift the beta label.

And we plan to lift the beta label sometime within the next one to two months. And shortly thereafter, we plan to release a federated model where companies can run Flurry, decentralized, but amongst a federation of companies. and that is something that we are looking to do by the second quarter of 2018, so not too far away. And it's probably around that time that we will have enough experience working with these companies on incorporating FlurryDB to feel like our protocols are sort of the right protocols and some of the methods that we have there are the right methods to open source the technology. So that's around the time frame that we look to open source the technology and get more comprehensive. community involvement in the code base itself.

And then, of course, the last main step is the fully public blockchain. That is something, of course, we would love to accomplish before the end of this year. But some of these other steps and sort of how they go will help dictate our timeline for that last piece. That sounds great. And we'll look forward to seeing the developments of FlurryDB and hope to see maybe a public Florida DB network sometime in the future. I know that that's something I'd be very interested in. dabbling around with in some capacity.

So guys, we could go on for days here. I feel like I've got so many more questions to ask you. I guess we'll probably have to have you on at some point again in the future. Perhaps, you know, when this dust gets deployed up as a public network, that might be a good time to have you on again. I just want to thank you for being guests on the show. And I hope that everybody learned a lot today from just your experience in technology and developing, you know,

prize software, I thought it was very valuable. Thank you. Really appreciate you having us. And thank you to our listeners for once again tuning in. We release new episodes of Epicenter every Tuesday, sometimes on Wednesdays, depending on on when we can record them. So do subscribe through the show on iTunes, SoundCloud. We're also on YouTube or your favorite podcast app on iOS or Android.

You can support the show by leaving us an iTunes review. It helps people find the show. We're always very happy to see those. And you can also send us a tip. The tip he can address is we'll be in the show of the description. We accept tips in Bitcoin, Bitcoin Cash and Ether. And thank you to those who have been tipping us over the years. So thanks so much.

And we look forward to being back next week.