#216 Brian Platz & Flip Filipowski: FlureeDB – A Scalable Blockchain-Based Graph Database

3 Jan 2018 · 1:06:26

Fluree co-founders Brian Platz and Flip Filipowski join Epicenter to discuss FlureeDB, a scalable blockchain-based graph database. They cover how its immutability and replayability improve enterprise compliance and GDPR readiness, the different consensus modes it supports across private, federated, and public networks, and why they structured Fluree as a Public Benefit Corporation.

Speakers

Topics

Transcript

[Music] hi welcome to epicenter the show which talks about the technologies projects in startups tracking decentralization and the global blockchain revolution my name is sebastian kuchela and today i'm once again doing the show by myself Brian and Mara we're not available so I'll be here today and I'm very pleased and very honored to bring you our two guests today Flip Phillip hausky and Brian Platz and those are names that you may recognize because they over the years so operated

in and around the periphery of the block chain space flip is one of the co-founders and partners of Silk Road equity and Ty Lee capital and previously because flip has a very long track record of building companies and in the technology space was chief operating officer of Kali net 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 late 90s sold for many billions of dollars

to Computer Associates and so we're very pleased to have flip on to talk about his experience in the software space and specifically with regards to selling to enterprise and Brian is the co-founder and CEO of Silk Road technologies and previously was co-founder of a list apart so for those of you who come from the web development space like myself will be very familiar with a list apart as we have a great resource for web development and web developers in general looking to expand their lot knowledge about web dev technologies and that blog still exists now and and today they're both here to talk about their new project called flurry dB

flora TB is a blockchain technology stack that caters enterprise and that specifically allows for decentralized distributed databases but they also have the benefits of blockchain technology in terms of the immunity idol et 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 we could spend this entire episode as sort of a how does like building software for enterprise like we could just spend an hour on that topic unfortunately well fortunately there's also

flurry to be to talk about but I do want to I do want to spend some time brain picking I I suggest I suppose and talk about your respective experiences and what you've learned over the years and you know 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 and all these things happened before and we've seen them before and people that were around them that 80's and 90's and probably looking at you know all these young entrepreneurs and going I like these mistakes they're making but first please I would like to both get your rap starting with flip respect

to backgrounds and how you got to be interested in blocking 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 for relational database systems were in play Cullen at was the purveyor of IDMS a codicils 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 benefit in enormous Li 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 Hui today recognized as a giant and so many different disciplines if it wasn't for the internet they could not possibly exist neither without the smartphone could we have a goober or a 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 taking from your

experience and how come knees have been able to navigate that changes that have occurred over the last 40 years right I maybe even fifty years like starting with mainframe computers and them databases and then the internet and then like the world wide 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 eat all of these changes that you have seen that we should have also applied to blockchain and that industry and enterprise companies should also look to a sort of a guiding light on how

they should look at watching 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 exists 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 percent 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 ten years ago well now maybe ten years and six months ago nobody knew what a

smartphone was and then in July of 1997 I'm sorry if 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 the 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 were 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 ecommerce and retail you know I came here to France about ten 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 this this sort of Sears Azure you know are like these retail stores that failed and

like disappeared in a matter of a few years but others that got through it what what would you point to as good strategies for adopting this technology rather than looking at is it a threat or like how can how can an existing company like a banker or an insurance company have some glimmer of hope that you know they will be around in ten years I don't really think there is a glimmer of hope but let's just say there is for the sake 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 did be gone sooner but they are for all practical as Kmart and for all practical purposes Ceres 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 Oberer and Airbnb have to worry about blockchain because with the deployment of blockchain they will be D 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 we run on the software that can be downloaded by those contributing autonomous vehicles as well as those that are picking up 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 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 I you know again coming from the from the

sort of commerce and e-commerce side before him previously to being in blockchain I think the companies that knew the few companies that were somewhat successful that managed to hold on to some sort of market sher 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 that are seeing some success in in these smaller more agile niche businesses that they were able to sprout as a means to adopt this this new technology which was

e-commerce ten years ago fascinating I mean I could ask you questions all day but 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 late 90s and early 2000s learning to code and do HTML and CSS like a list apart 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 and Jeffrey's Elfman did a great job there and really benefited to to that whole community and of course that list apart is still around and I don't read it so much anymore cuz and I don't code but but I

do see articles come up once in a while and that's always great to see it there so yeah please please tell us about your journey in this space starting you in the 90s and now how you've got into blotching 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 and

blockchain technologies here but I have been involved now with six or seven different companies and starting them and and being at least a core part of their origination most of them dealing with their enterprise software internet internet-based technologies probably one of the more influential times was at 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 they

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 flipped brought up had 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 have been working together now for since I think 1999 about 18 years and the last company that we founded together with 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 Fleury DB and what what what lessons again I'd like to throw in the question to you now what lessons do you think we can pull from from you know these early days of the web and so the the startups that were emerging in the late 90s and early 2000s that may be valuable for blockchain companies now and and the same sort of

challenges that they're facing with regard to selling to enterprise and sort of think 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 ultimately people buy solutions that solve problems that they're having and oftentimes even the problems that people describe themselves are 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 get 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 the key is how do you get into that two or three that actually get purchased 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 it'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 you're you're just under so much technical debt the competition picks up it's a very very challenging place to be and 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 focus for people to get to the next round of the fight that's interesting because this is this is something that I've been thinking a lot about in sort of my in 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 accelerating last few months is seemingly a sort of homogenous Asian 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 it's getting to be indistinguishable what are your thoughts on this and how do you think companies can differentiate themselves from others when in fact they're their infrastructure although the technologies may be different the implementation may be different the 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 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 sa P's the Oracle's they all had a similar stack and one of the things that you saw them doing is vertical izing

tremendously I mean they have vertical blueprints for if you're 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 different differentiator around that becomes some of this sort of content mark and some of the sales but a lot of its the services it's the people that are rapping together these specific solutions out of these general technology fascinating we could spend the entire episode and more talking just about this but let's let's talk about the what we came here to discuss and that's Fleury

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 and III really appreciated the architecture and the way that you're implementing this technology so please tell us what is Florrie DB and what what problems does it address specifically in the market that you're targeting sure so Fleury DB is a database that at the core 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 you know that's kind of the aspects of power every database and then there's layers

on top of it there's layers that enable easy querying there's layers that enable security there's layers that enable all of these sorts of things and Fleury DB is is similar except that the core is blockchain and then we have layers built around that to support query and to take advantage of it what 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 black chain 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 is 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 in in addition every single application developer who's up 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 flurried DB 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 half 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 chain DB that try to take this database or I guess they try to blockchain if I database as 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 aetherium perhaps can uniquely solve then that's great you can go to aetherium 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 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 aetherium 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 in a kick by the 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 five million u.s. dollars to

store gigabyte of data on the etherium 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 on to aetherium 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 were existing blockchain technology there's sort of this trade-off between very public being the public block chains 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 ten minutes to confirm transactions aetherium even fifteen seconds there's a cost in there that 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 advantages on speed but then there's other sort of trade-offs and another thing we really wanted to address with flurry DB 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 Fleury DB aims to address this we call this concept hyper 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 parts of it need to be there I do agree with you a hundred percent that you know as these technology stacks mature we're going to see a so 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 aetherium has the ability to perform transactions at a cost right and and those transactions are of a specific nature and and mostly related to you know putting some kind of a some 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 of compliant with regulation and like gdpr and this sort of thing you're gonna need something different from that but that's that's very similar to 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 for data for api's for for the for the business logic itself and and I feel that we're going in this direction of watching as well and anybody who fails to see that just needs to look it who 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 if from what I understand reading the white paper and then looking through website Florrie DB is is a stack of of technologies that incorporates this all these notions that we know about blockchain so that's like immutability the the ability to record

to the state of data in time access controls these sorts of things but does it in a way that where you can store significant amounts of data in a no SQL format can you expand on some of the technical aspects of Fleury DB 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 Sports 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

rethink DB or big chain DB which you brought up which is also built on these no sequel 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 we're trying to do internet something and you know internet is now in everything it's just a feature and black chain I believe should also have that 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 it 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 your go without going to a backup tape and restoring the database if you still have it zero days I mean as I was reading the white paper I was thinking like this

this is so this is insane that I'm like no database stack that we use today like SQL in your SQL or 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 your Mac or 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 except today were created they 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 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 Oracle's 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 back fill in with blockchain they can't add these features and simplify the way that you can if you're starting from scratch knowing what the technology constraints of today are and I think that answer is 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 - it's a it's a amazing certainly I have and other people who have used this you start to change how you develop things for one there's a certain comfort knowing that you have everything though 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 12:15 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 in 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 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 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 like this let's let's let's dive right into them sure it was a good example application for one we wanted to build some applications that leverage 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 two years we have seen start try to manage us on spreadsheets different people have different versions someone thought they had you know one point three seven percent based on something they were told in February and you know now they're getting something and says they have one point three six percent and what changes I mean is constant so the idea that you could build an application input zero additional effort into a feature set that would allow you to rewind history to any point in time and get an instantaneous response was a pretty you know 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 developed an application they know it's a lot of effort first you need to decide upfront what you're going to be tracking history up you end up creating a totally separate set of tables to track that data the relationships that 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 the pretty powerful concept very interesting I can I can definitely see how if you indeed if you have this technology stack that you can just plug into your existing application and there's will reap the benefits of this this idea of time travel and we'll get into that so technical aspects in a second here but 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 let's talk let's spend some time then on the technical infrastructure and some of the elementary component of Fleury db1 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 second 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 time 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 black times and a lot of block chains continue to decrease but there's gonna be a certain limit that they are gonna have a hard time getting over I don't know what that is I 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 in the transparency which comes at a cost where we need and we 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 though there 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 this kind of brought us into the realm of actually doing graph database joins essentially across different databases or segments in 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 trans actor something always has to know the 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 black chains 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 for 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 your application queries into and they will relay transaction data to your sort of single trans actor 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 it currently I think you're at the stage where one can deploy they sort of internally and have all these features that we mentioned and then further down the road at some point we'll have the the ability to deploy this as a federated 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 a like a public network that one can use you know with any type of application talk about the difficut I'm in it 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 pseudonymous and if you have a more federated model than 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 vs 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 a the needs around a fully decentralized public consensus mall or you can use that internally if you want but in many cases it doesn't make sense so a round of feting federated model what we see a typical requirement being is a group of you know 10 20 30 50 100 whatever it is companies deciding that they are going to run a database decentralized but amongst 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 in 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 you may have a tender mint style Byzantine fault tolerant consensus essentially which is like a voting mechanism yes yeah a voting mechanism where they would approve and 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 in 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 in 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 database is from a federated model you're also as a business going to 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 transact or internally the other benefit you get is you do get a pretty strong sense of tamper resistance from that so tremendous amount of money is spent on auditing of course with companies and you know we've been doing this for years even as a software organization trying to comply with SAS 70 or now the sSAE 16 or ssa 18 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 you know regular performance of disaster recovery activities whatever those controls happen to be by having a core immutable blockchain even though you're running and 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 maybe 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 miners you end 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 ten 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 first 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 zero dollars 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 a mind to be able to help out is something we would like to see yeah I agree that that there's a massive benefit in having these public database infrastructure layers readily available frame anyone to use I mean they're like you know 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 first of a website from 20 years ago you know if

if a snapshot has been taken on the other hand you can't look it's a P I data I mean you can't say like what was the what was the result of this API call five years ago or ten years ago or even just yesterday and I think there would be there's a lot of benefit to having and if you can have that as like as a publicly available network that anybody can can can access and applications can plug into and and send data to it and it can be stored there then it 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 break compliance and and I think that obviously this this is a 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 so okay well I mean I I know that I have all of the records here because the database says so and it's it's sort of built in that I can time travel and go back and I 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 just a few months out are still struggling to to figure out how they're going to be compliant with gdpr

and all of its requirements and so it I'd like to get your thoughts on how GPR how Florrie DB 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 recording reporting requirements and that sort of thing yes 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 ripe for efficiency and I can say just our last company Silk Road technology we spent almost $100,000 a year not 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 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 you know basically coming in and do playing detective about because you do have this source of truth that's difficult to manipulate well we talk about the right to be forgotten that is sort of it

almost as odds as it can get with the concept of a public black chain 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 the data in flurry dB if it is the type of data you want to store there to be able to do so one is that flurry DB 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 in database transaction functions that actually allow data to be manipulated

within the database itself one of the things that we have is 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 for 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 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 it's 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 identifier on the public blockchain that does not have any personally identifiable information on it that can be joined with in internally run Fleury dB 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 is you know figure out why you need to store this

data on a blockchain to begin with and you know it isn't necessary and in some cases it may not be great that's all very fascinating and I I'd love to talk some more about the technical aspects we 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 just one thing that's very interesting about this about this this company is that you've set up as a public benefit corporation flip could you talk about why you chose this structure and what would it 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 retrack tits an immutable characteristic of the 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 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 and so what are some of the things that are the specific things that that your company is sort of within the Charter says it will do any point in space anything specific yes I think that in 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 you know a lot of a lot of jobs will disappear in the next you know 5 10 20 years or disappear or will will will morph will change I think the landscape of employment will be very different in the next two decades and if if companies that are contributing to that change can somehow make some sort of an engagement that you know 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 the we all stand behind anything yeah it's important to understand that the nature of a human beings 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 these 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 the complex problems of unemployment that will result as a as a result of these various technologies being available and the I guess the Moore's Law of making them reach singularity and the not-too-distant future

well it's a very noble cause so before we wrap up here can can we get some some insights about development roadmap we're where we currently mean I know you mentioned all these different and the different steps and deployment so 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 it currently flora TB is not open source why is that and do you plan to open source at some time in the future yes sure so unknown source question absolutely we plan to open source it it is you know in 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 where of course were 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 of working with several organizations software companies primarily who are looking to use flurry DB 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 flurry DB 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 sources of technology so that's that's around the timeframe that we look to open sources of technology and get more community involvement in the codebase itself and then of course the last main step is the you know 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 that sounds great and we'll look forward to seeing the developments of flurry DB and and hope to see maybe a public flow DB network sometime in the future I know that that's something that I'll be very interested in and dabbling around with

and in some capacity so guys we could go on for four 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 when this does get 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 from just your your experience in in technology and and developing you know enterprise 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 when we can record them so do subscribe to the show on iTunes SoundCloud we're also on YouTube or your favorite podcast app on iOS or Android you could support the show by leaving us an iTunes review it helps people find the show and we're always very happy to see those and you can also send us a tip at a typically interested we'll be in the show the description we attend we accept tips Bitcoin Bitcoin cash and ether and thank you to those who have been tipping us over the years thanks so much and we look forward to being back next week [Music] [Music]