Transcript: Scalable Blockchain Database for Decentralized Construction Apps

you can define the schema and you in a sense are almost creating your own blockchain based on that characteristic. You know, a great example of leveraging this is to solve litigation. Of course, litigation costs an immense amount of money in construction. And of course, a big aspect of this is just figuring out what happened and who's really liable. You know, many of these things don't often end up getting litigated.

They end up getting settled once a whole bunch of lawyers spend a whole bunch of time reviewing a whole bunch of documents or information and trying to figure out who's got the upper hand. Perhaps the bigger cost is streamlining these litigations and getting all the cards on the table, so to speak, and doing that quickly. We have the ability to actually reduce the timeframes of that discovery and everyone getting on the same page as far as what happened and when, what information was there at any point in time in history, but because of the immutable characteristics, I have the ability to know that it hasn't been tampered with in exactly when it was done.

Hello and welcome to the Constructor Podcast, the best way to build it, episode number 71. I'm your host, Brittany Campbell-Turner, and this podcast is dedicated to helping property owners have certainty in their decisions about their construction projects. We talk about fostering trusting relationships, helping understand how to lower risk, be under budget and on schedule, and most importantly exceed your end user's desires. So last episode we spoke with Ulfahamdi, founder and executive director of the Advanced Work Packaging Institute and the CEO at Concord Project Technologies. Last episode she spoke about how advanced work packaging drives definition and planning within the construction sequence at the beginning of the project and the benefits.

She argues that a more defined project execution plan is a key to managing complexity and to more efficient cost-effective construction on major capital projects. So if you haven't listened to that episode yet, check it out at constructor.com. In today's episode, we're speaking with Brian Platts, the co-CEO at FlurryDB. FlurryDB is a scalable blockchain database that combines enterprise capability with blockchain proof and security. We deal with databases all the time.

Your BIM model is really a database. Any project management data is in a database. And what FlurryDB can allow you to do is to streamline litigations, reduce the timeline for a discovery period and while you're reviewing the data itself, so you can clearly understand what happened and when. With that, let's get into the interview. Today we are talking with co-CEO Brian Platts at FlurryDB.

FlurryDB is a scalable blockchain database that combines enterprise capability with blockchain proof and security. So Brian, welcome to the Constructor Podcast. Thanks for having me. I'm glad you asked me to participate and to talk about blockchain. If you could give us a brief history about databases.

Sure. Well, databases go back further than I do, so I can only get to a certain point. Mostly, the relational database with several versions that predated it was created almost 40 years ago. Still really the main type of database that we use today. This is the oracles of the world, the MySQLs or Microsoft SQL Server.

These are all sort of traditional relational databases. They were built in a time where things like hard drive space and memory was really, really expensive. So there's a lot of design decisions that went into databases at that time, which were appropriate decisions for that time. But a lot of it we continue to obviously use today. Technology takes a surprisingly short amount of time to be created or come up out of the blue, but a long time to sort of dissipate.

There's a lot of modern database technologies that have come up in the internet era. These are things like NoSQL or document databases. Really, their origins focused mostly in the past five to 10 years around internet scales. So these relational databases weren't necessarily designed to power things like a Facebook or a Twitter in that sort of scale. So these new types of databases really focused towards scale at the expense of some of the kind of core, more enterprise features of databases.

So we've got some modern entrants, all of which usually make some degree of trade-offs to try and accomplish what their goals are. What's likely the case with a lot of the audience members is that we all use databases on some level. We may not exactly know how they're sitting behind the user interface of, say, the Oracle software that we're using or the P6 Primavera or even Microsoft Project or any of the cost accounting programs that we use. But you talked about the different database types. They're all very much what's behind these applications, right?

Yeah, they absolutely are. In fact, almost every application that anyone uses today and for some time are based on kind of a three-tier architecture. And the top tier is what we're used to using, which is your iPhone and an app on your iPhone or a web browser app. That's sort of the UI tier. And then there's always an application tier, which kind of controls some of the core rules, permissions, things like that typically.

And then they all have a data tier, and that is the database. And that is where all of the information gets reliably stored so that the application can use it. So pretty much every application that you currently use or have ever used have those three tiers. They all have a database as the foundation. Could you now explain what blockchain is from a database perspective?

How we've approached the blockchain problem is more from a data perspective. So there are a lot of blockchain initiatives out there. And the focus of most of them is really on transferring assets. Of course, the most famous being Bitcoin, and there you're transferring tokens as a monetary value. And there's others that are trying to focus on transferring other assets that might be represented by a token, but they could be a piece of art or they could be a product or something like that.

But that tends to be the focus. When you build an application, they all do have this need to store and persist data. And so that's really been the approach that we have taken with our particular project is combining these blockchain characteristics with the idea of, instead of transferring an asset, actually enabling you to define the type of information you want to store and being able to store it, but have those blockchain benefits like the tamper resistance, the decentralization, the trusted model. Those are things that aren't inherent in database technologies and really blockchain adds those to the database side for us.

Nicole Soule That's one of the main reasons why I have been investigating blockchain here on the podcast. I think that there's so many really unique elements and components of what blockchain can provide. And I think that it's definitely a unique perspective in the way that you're approaching databases for sure. David Schroeder When you really boil down most business interaction that isn't purely transactional or sort of financial, it involves sharing data and sharing information. So for us, it's a very natural spot to bring these blockchain characteristics.

And we think it actually fits most of what businesses are trying to do when they're trying to take advantage of this type of technology. Nicole Soule Absolutely. And I think that most of the applications that we've been talking about have been focused on the private versus public approach to utilizing a blockchain and also a federated model as well. But before we actually get into that, because I want to dig into that with you, could we just talk a little bit about the unique property of hashing?

David Schroeder Yeah, well, hashing is a core part of blockchain technology. And the hashes are actually put together and arranged in something we call a Merkle tree. It was actually invented or gained popularity from an individual with the last name Merkle. That's where the name comes from. What it is, is basically taking pieces of information.

You can think of it like if you had a Word document and you keep running all the characters in your Word document through these mathematical algorithms, and end up coming up with a very short string of information that summarizes that whole document. It's lossy in that, of course, if you had a full page Word document, and now you have the short string, you've obviously lost a lot of information. But the idea is that these algorithms will detect or produce different results if you even change one single character on that original Word document that resulting kind of short string will end up being different.

And at a core, that's sort of what these hashing algorithms do. They don't have the ability to store all the information all the time, be able to share and kind of build these consensus models across the globe, transmitting all this large amounts of data. So if we can kind of summarize all those data into these small strings, but those strings in these hashes basically prove that the data hasn't been changed, then we've accomplished the goal, but we can actually arrive at agreements on the data very efficiently and fast.

So the other sort of fundamental basic, could you tell us what sharding is? Sharding is a strategy that lots of things, but in particular databases and data and blockchains utilize to try to get scale, to try and process more transactions. And the idea is that if you have every single say visa transaction, because everyone knows about these visa transactions and sort of the massive volume there is going across the globe, and you tried to process every single one of those on your laptop, your laptop would probably have a very difficult time keeping up with that type of information.

So sharding is a strategy where you sort of break up the work across multiple machines. And really the only reason to pursue sharding, because you want to scale, because you want to be able to process more transactions per second or per minute or whatever metric you're going for, you're just breaking up the data sets. The challenges that come in with sharding is that as long as all the data and information you're trying to work with is within the same shard, for example, if I'm using a visa payment and my visa information is in the same shard at say target where I'm trying to use it, then all the data is together.

But what if the target data happens to be in a different shard than sort of my visa information? Now we have sort of this more complicated issue that we have to figure out a way to go across these shards of data to do transactions. So that's really the downside of sharding is that it adds a lot of complexity when you need to transact or move information across shards. So as long as you can keep the data within one shard that's commonly used together, things can be incredibly efficient and scale really, really well.

But you have to design it carefully. That definitely provides some context. Get into the discussion a little bit more about databases. What are some of the solutions that blockchain can bring to databases? And feel free to talk about how FlurryDB is capable of doing that.

At the core, what blockchain is adding whatever it happens to be dealing with is this idea of trusted information visibility, extreme tamper resistance. We talked about some of the hashing and that really plays into this notion that data cannot really be changed or it would be extraordinarily difficult to change data. So it implies this trust in the information. And really the hardest part of this that isn't very possible with other technologies is the idea of decentralization. The idea that multiple parties, in the case that we focus on, companies and organizations, can actually share data or share transactional information but do so in a way where no one actually controls it.

And if you think about anywhere that multiple organizations are working together on anything, in every one of those contexts, somebody's actually controlling it. And maybe the other parties have the right to audit the data or things like that. But at the core, somebody is controlling it. So blockchain opens up this notion that all of a sudden we can actually work with the same set of data information, transactional set, whatever the case may be for a particular blockchain. But we can do it in a way where no one actually controls it.

We're all equal participants in a network and the whole network is maintaining the information. So we really apply all those characteristics to maintaining a database. And one of the things that some people describe blockchain projects as, as databases. And they are sort of loosely defined, I guess, as databases. So the Bitcoin blockchain is a database.

But it's a database with sort of a predefined schema. It only holds about five or six different types of information in it. It's hard coded in there and it's focused on transacting money. And really what we bring as a blockchain database is the ability for you to define the schema. So you can essentially define, in essence, your own blockchain, the type of data it's going to store, whether it's storing information about a project that's getting managed or information about transactions or information about products themselves.

You can define the schema and you in a sense are almost creating your own blockchain based on that characteristic. So those are some of the things that we pulled together and try to give this flexibility for organizations to start to leverage and get some of these benefits we talked about. I think that's hugely valuable in this sense, because I think that for most projects, there's a plethora of data, like I mentioned before, the project management tools that we already use that we're trying to track. I think that we do a great job, but there's nothing like doing it with a decentralized approach.

And in addition to that, the immutability of blockchain, having all of that, the information recorded and it cannot be changed, or you can trust the data because you know when it was put in, it was verified and now it's accurate. I think those things are really, really helpful from a project perspective. And blockchain enables you to basically put code that forces these rules to happen. So that really gives the integrity to the system. And yeah, this hashing and immutability characteristic allows you to know that certain data was there at a certain point in time.

And even if someone made a mistake and they updated the data, that's fine. This happens and even in banking. But what normally happens is you don't go back in say a bank statement and change last month's bank statement if there was an error. You end up having an adjustment on the next bank statement. And blockchain really sort of has to work like that.

And I think it's good to have it work like that, where you're not actually ever able to go back and change data, but you can constantly say, oh, you know, this was a mistake. So we're going to make this adjustment or that adjustment. But every one of those adjustments is there. It didn't override anything else that used to be there. And it gives the integrity to the information.

Exactly. And I think that what we do a really good job of in construction projects is we try to point to the data to describe what happened. And it seems as if we have lots of different sources that is helpful. But then sometimes it's, you know, depending on where it's coming from, it could be interpreted differently. Say something as simple as, hey, when are we shipping X item?

And when are we expecting it to be delivered? The to from ideal, it could be shipping from a yard to a manufacturing plant, from the plant to some storage space and then come to the site. And everybody's definition of that could be different. I think that having those types of indicators clearly laid out and like you said, customizing the code in order to pull the exact information that you're looking for is really quite helpful. Yeah, I would say it's really helpful.

And this is one of the key areas that people are seizing on blockchain as a really quick win. You know, all businesses have different languages. And whether it's the example you gave around shipping times, or maybe you're dealing with a particular product that someone calls by a different name or has a different skew number or whatever the case may be, this is a way for organizations to centrally store and manage data. They can still apply their own unique aspects to it, but it's centralized in that everybody has visibility all the time.

And when we think about these sort of supply chains, whether it's, you know, just the transportation of items, or whether it's a seller to an original manufacturer, there's all these people who get in between and linking and getting the data all the way through that chain. You know, it's like, I'm trying to think of the old game, maybe you know it, where you pass the message to your neighbor and you see if it's the same message by the time it gets back around you. Telephone. Yeah, so it's that exact sort of problem that's happening all the time.

And this is really an amazing technology to get in the middle there and let everyone get on the same page and let everyone trust that central source. Yeah, exactly. And I think that's what brings us to a question I had about what a federated model is. I know I mentioned it before, but could you give us a brief description of what that is? What we call federated, and sometimes you do hear the term private, we actually define private as something different, but a federated blockchain is one where you have a known set of organizations that are participating in whatever the blockchain is doing.

So in our case, in participating and maintaining the database, but if it was a different blockchain, it's whatever the purpose happens to be. So this is different than a public version where a public version, you do not actually know the participants. The participants will always run by the set of rules that are defined for whatever it happens to be, but you don't really get a say as to who is going to participate in enforcing those rules or not. And the way blockchains are designed is that so long as at least two thirds of the network is playing fair, integrity will always be maintained.

So basically anything more than a third of the network, typically the network itself is at danger or could be overwhelmed. In the case of a lot of these blockchain technologies, it's the cost of getting even up to a third of the network is so extreme, that would always be very challenging. But the key there is that you're not in a public model. You are not choosing who's participating. Anyone can participate, which is part of the purpose of the blockchain.

It can just run by code. It doesn't need humans to get involved and interpret. That comes with obviously visibility of the transactions and visibility of data. So this is why the federated model is so attractive to a lot of businesses in that they can run it amongst a predefined set of parties and only those parties have that visibility as opposed to the full world. Yeah, exactly.

And I think that leads me to my next question about handling permissions. So what I understand from a couple of the talks that I've heard you've done is that when it comes to permissions, just accessibility to particular information, that that can be coded into the databases themselves versus say like the application that you are utilizing. One of the things we had to put in to FlurryDB was the ability to control who can update what data and under what conditions. And lots of times I talked about the tiers in the applications earlier.

Lots of times you would actually put that logic in the application tier. But to run as a blockchain, it actually needs to be with the data itself. We think now that we have it in with the data itself that this just solves all sorts of different problems because what you have the ability to do is actually secure the data at the source. This means that, for example, people building applications that are leveraging this data, you don't have to worry about them, say, accidentally exposing information to someone they maybe shouldn't have or accidentally updating or overriding someone else's data because their applications now do not have the control over what data they're allowed to see or what data they're allowed to update.

And when you start to think about even multiple applications sitting around the same data, which is often what you're trying to achieve, you have these kind of big master databases inside of an organization and you may have 10, 50, 100 different applications that are all leveraging that same data set. Today, the permissions are actually encoded in those 10, 20, 50, 100 different applications. And of course, how they're coded into those can all be different and could leak out data. But if you actually can put the permissions with the data itself, then you never ever have to worry about this issue happening.

The data is secured at the source. And years ago, this would have been very difficult to do at the database tier. But really with how fast computer processors are today, how much we can leverage memory today, we can actually make this extremely efficient at that core level. And so we've done that, of course, not only to power the blockchain, but we're realizing all of these other benefits from having that in there. I want to look at this a little bit from the perspective of the owner, for instance, and ask the question, where does the data sit?

Say I understand the permissions and who I'm allowing to update and view the information. How do I know where it is? How do I plan for, like you said, the storage? How do I plan for the speed? Those are the types of questions that I'm asking.

Could you sort of give me a step-by-step understanding of how that compares to what I would be planning for today and then what that looks like on the blockchain? It actually wouldn't differ that much from how you would plan for it today. The only difference is that here you do have an option of actually not running the storage as well. But you would have to have, assuming you're participating in the network, so this is kind of this federated model that we talked about, you would have to have the capacity with your machines that you're running or someone else is running on your behalf of storing the amount of data you're planning to store.

So if you're going to end up storing a gigabyte of data, of course you're going to just have to make sure that the machine has a gigabyte of data available to it. So it's the same things that you would be going through to store data in a traditional database. You're doing what we call capacity planning, just making sure you have the space to participate. I guess the key difference is that if you choose, you have the ability to actually not run the transactional parts of some of this data and actually pay people to do that on your behalf following the rules that you set out.

If that's what you're looking to do, then you technically don't have to run the data at all. And where it sits is in this node of computers, potentially across the globe or across your network that are maintaining it on your behalf because you're paying. You're essentially paying a token or a fee to them to process new transactions and keep that data up to date. In our model, because applications like to have data very close by that they can query and get really fast responses so that you have good user experiences in your apps.

If your app was trying to load up and say, look at the current project status for a construction project you're working on, and it took three minutes before the screen painted, you'd probably get frustrated. So we have built the ability to actually run additional, what we call query nodes that can sit right along with your applications. And they allow you to get that super fast database response times for your applications. So if you did want to build your own applications, you're probably going to want to run some of your own query nodes to get that user experience down.

I've experienced that three minutes of the screen being painted with P6. So I can certainly identify with that from a scheduling perspective. I just see so much value in not only the capability to store and have many people taking care of the transactions. The speed aspect is really interesting to me. How does that happen?

Yeah, I think one of the sort of least appreciated part of blockchain technology is the idea that if you're having all of this trust and all of these features that we didn't have before, there's two reasons we didn't have them before. One is that the sort of a good framework for doing it didn't exist. But the other is that it actually comes at a cost. And so when people are looking to leverage blockchain technology, there's kind of two parts that often end up surprising them that they need to work around.

One is how long it takes to process a transaction. So I'll use a simple example of maybe trying to use Bitcoin to pay for a cup of coffee. Bitcoin takes 10 minutes to process transactions at the earliest. And then some people don't even consider them fully confirmed due to some nature of blockchains until two or three blocks have even been mined after that. So to have something really, really solid might take 30 or 40 minutes.

Now that's sort of an extreme example, but that's a good example as to why a simple, quick, practical transaction might not be possible. You're running into the cost of consensus, this massive global network of computers that all needs to communicate with each other to agree. So that takes time to do. We can get those times down quite a bit from Bitcoin. Of course, it was an original one, but it does take time.

There's no way to sort of get around the fact that just sending a computer message from one computer, say in the US to one computer in China takes about a second for it to actually get there. And then if all these need to keep communicating back and forth, that time compounds. So it takes a lot of time. The other part is the cost. So part of this is the market that is defining the costs of these things.

And I think it's a little out of line with the true cost of it. But today, processing a Bitcoin transaction is now up to the point where it costs about $30. So again, not real practical to buy a $2, $3 cup of coffee if it costs you $30 just due to the transaction. Other blockchains that don't have these characteristics of Bitcoin can do this much faster and cheaper. So it's technologically possible, but it does come at a cost.

Where we get into this really from a data side is that these blockchains are not really designed to store data. So the main public blockchain that exists that has characteristics to enforce smart contracts, the idea that maybe you're putting money in escrow or you're putting conditions on payments or these other sorts of pieces, the ability to put data on that, it costs about 10 million US dollars today to put about a gigabyte of data, which isn't that much data to put on that. So these things really are not designed for holding data.

And that's really one of the unique characteristics of what we've built with Flurry. I mean, that could be up to 20 some odd gigs of data. That's going to be a huge cost for me if I ever want to consider putting that in a typical smart contract. Maybe a hundred million dollars. Yeah.

So obviously it's not practical for you to do that. Again, that's why some of the people are excited about our project is because it does really focus on managing data efficiently as opposed to sort of some of the financial or currency aspects that most of these other projects do. To make this easier is that what parts of your data do you really need to store on the public blockchain? And the answer may be none. All of it can be on the federated.

The answer might be a tiny bit of it, but other parts of your data you want to store on the federated network. And maybe there's some really internal data, maybe linked to internal employees or something that you don't want anywhere except for internally. And so we've introduced this concept of hybrid consensus and the idea that you can take the data in your database and parts of that data, just the parts that need it can be verified on public consensus if that's what you want. And you're willing to wait for the delays that are involved in that.

Part of it can be run in your, just your own network of companies working on a project or in a supply chain. That can be done for free and very, very fast. And then part of it you can just run internally because you don't want anyone else to see it. The idea here is that we can actually pull all that data together and make it look like it's one big database to your apps, but it's actually coming from different sources, each of which have these different blockchain consensus and cost characteristics.

That's just really exciting to me. The audience who looks at things from a smart cities perspective, if corporations want to take their information and contribute to different governmental agencies, public agencies, and support them on their initiatives, I think that could be super valuable and then valuable for the corporations just as much taking information about utilities and things like that. So I can definitely see the applications there. Yeah, we're excited about the ideas of people launching just databases that exist in the cloud that house information that they're interested in.

And we think other people will end up probably being interested in that information as well and participating in storing it. And whether it's something like government records or, as you mentioned, utility information or energy related information that's going to help the planet become more energy efficient. Or it could even be information about global climate change or the human genome. The idea is that these databases can exist in the cloud that people can participate to help maintain them. It's really exciting technology that doesn't exist in any other way that I'm aware of today.

So I want to talk about this notion of time travel. We didn't know that we could do that, I don't think in real life, but we can do that with FlurryDB, right? What is it? And then how can we potentially use that for running audits? Yeah, it's a really exciting thing.

So every blockchain has a complete history of everything that's ever happened. And really, most blockchains think of this kind of as baggage. It's necessary to prove the authenticity of the blockchain. But normally, I'll use Bitcoin as an example. I don't really care whether or not if you're trying to pay me two Bitcoins, which today is a lot of money, whether or not you had two Bitcoins a month ago, I care about if you have two Bitcoins right now.

So the idea that what happened a month ago or a year ago isn't that important in a lot of these contexts. So that's why a lot of blockchains kind of think of this as baggage, a burden, a necessity. And one of the things we've done with FlurryDB, because again, our focus is on storing data, is how can we come up with a way where you can actually turn that historical context into an immediately accessible asset? And this notion of time travel is what we focused in.

And the idea is that you can ask the database a question about whatever data you want, and those questions can become pretty sophisticated. But you can optionally specify when you want that answer as of. If I want that answer to know what the exact budget said at a moment in time, a month ago, a year ago, three seconds ago, I have the ability to do that with FlurryDB. And that is not a capability that you have in traditional databases. And how this impacts things like audits is that not only can I instantly access what information was there at any point in time in history, but because of the immutable characteristics, I have the ability to know that it hasn't been tampered with in exactly when it was done.

A great example of leveraging this is to solve litigation. Of course, litigation costs an immense amount of money in construction and most other industries. And of course, a big aspect of this is just figuring out what happened and who's really liable. You know, many of these things don't often end up getting litigated. They end up getting settled once a whole bunch of lawyers spend a whole bunch of time reviewing a whole bunch of documents or information and trying to figure out who's got the upper hand.

And once all that's discovered, it gets settled. Well, by leveraging this type of technology and having this trusted history, we have the ability to actually reduce the timeframes of that discovery and everyone getting on the same page as far as what happened and when so much more quickly not only can impact auditing cost, as you mentioned, but perhaps the bigger cost is streamlining these litigations and getting all the cards on the table, so to speak, and doing that quickly. Time travel, it's got a lot of benefits.

It's got a lot of benefits from the application and developer standpoint as well, but from a real business context, we think it is a killer feature. I do too. And I guess I wanted to understand how could you potentially use the time travel feature to investigate what's happening in the future, or at least report in the future? I want to understand that. Well, we can't really investigate something that hasn't happened yet.

So we haven't quite got that advanced yet. What we can do is actually come up with different future scenarios, and we can leverage our tools to understand the impacts that that may have on different aspects of the business. So this idea is that time travel we support, not even historically, which is of course all concrete and can't be changed, but time travel into the future, but the future with multiple different scenarios. So if you wanted to evaluate what happens, for example, if a particular manufacturer doesn't get your product to your construction site by a certain time, and how that might roll into other impacts on other things that might happen, you can actually mock up essentially the data.

As though that event happened, it doesn't actually get transacted, so it's not part of that permanent record, but you can then run your reports or your analytics, whatever sort of applications are leveraging that information, as though that information actually happened. And you can try this with multiple different scenarios. So it's a really powerful tool to kind of do those what-if scenarios and understand what kind of impacts represent the most risk to your business, and what things you might want to be more careful about or help ensure.

I love that idea that you can extrapolate what the data that you already have in order to identify the potential scenarios in the future. I think that's also hugely valuable. So use cases. I know you talked about supply chain a little bit already. What other applications is FlurryDB looking at as it relates to the field?

We've talked about just managing data related to business activities. Supply chain, of course, is a good example where there's multiple parties involved. Things like project management and understanding what different parties are doing as it relates to a longer-term contract is, of course, an excellent example. Being able to actually share information about products is a really good example where a publisher or manufacturer of a particular product can publish information, prove that they're the ones that publish it, and maintain it in a central way that different organizations or even different pieces of software have this easy central access to that particular data.

One thing that you had brought up at one point was the building information modeling and the idea that perhaps the renderings of some of these building materials and products can be stored in this cloud database along with even maintenance information, how much it's going to cost to maintain it and keep that data up to date. There's really just so many different applications because really every application sort of needs a database at the core. And thinking about it from that owner-operator perspective, exactly like you said, how do you maintain the equipment that you have?

I mean, honestly, I'm collecting closed out documents right now for one of my projects and I'm pulling together operations manuals. I'm pulling together as-built drawings. I'm pulling together warranties. Those are the types of information, data points that I can pull from an automated transaction of information. I can have access to that at any point in time when I need it down the line.

Is that clear? Yeah. I think so. And the other piece of this that we haven't dived into, but is probably one of the hot areas around cryptocurrencies, almost the more currency aspects, is this notion of how does this impact industries around things like insurance and payment processing and cross-border payments? All of these stand to be made immensely more efficient due to blockchain technology and will benefit businesses that rely on them.

And certainly construction industry relies on all of these aspects quite heavily. Is there anything that we haven't touched on yet that may relate to this industry, whether it's corporate real estate or construction that comes to mind that you would like to share? Well, there are some interesting energy use cases that have been brought up to us. We are generic. So what we want to do is help people take some of the ideas and expertise that they have and pursue it.

Yeah, there's lots of interesting applications across the entire energy sector as far as sharing energy, tracking energy utilization, making that data available for others to analyze and make things more efficient and doing that not only at sort of a large public scale, but even doing it at a building scale. So please tell us where can people find out more about you, find out more about FlurryDB? How can they interact with you? I guess the easiest way is our website, which is just simply flurry, F-L-U-R dot E-E.

So just six letters in the domain. From there, we have some information about FlurryDB. We have ways to contact us if you wish to do so via phone or via email. And we also have a beta version available of FlurryDB to allow people to actually use the technology today. And all you have to do is give us an email address and you can actually start leveraging the technology and seeing how you might have ideas to apply it to your different expertise.

So we encourage you to do so. Wonderful. Thank you so much, Brian. This has really been very informative and really fun. Well, it's a lot of fun for me.

So thank you so much for having me. Thanks for listening to this interview with Brian Platts. Find out more about Brian and FlurryDB at constructor.com slash E-P-71. If you learned something valuable in this episode, share it with your friends and colleagues. You can also let me know if you enjoyed our discussion by connecting with me on Twitter at Brittany underscore CT or find me on LinkedIn.

Or you can just email me too at Brittany at constructor.com. That's B-R-I-T-T-A-N-I-E at construct double R dot com. Next week, we are interviewing Michael DeLacy, principal and co-founder and microdesk. He assists in AECO. That's architecture, engineering, construction, and owner companies.

He helps them to overcome the challenges of implementing and utilizing design, construction, and facilities management technologies. I look forward to sharing this interview with you guys next week. If you haven't already subscribed to the podcast, you can do so at your preferred podcast player. Please leave a review to show you support and let me know you're enjoying the podcast. I look forward to talking with you guys next week.