Chainlink Web3 Summit HackerNode: Providing Real World Data to Blockchain

This is something better. So we are having Streamr,
we are having kaiko, we are having
data, we are having CLC group in terms
of experience, of course, which is
the blockchain world. I guess basically, to
start this panel is for everyone to introduce
themselves saying, what you're doing. And we can get
started from there. I wonder if the neighbors
are a bit noisy. No, I think we'll be fine.

All right, so I'm
Henry, co-founder. I'm head of the Streamr project. So what is Streamr? Streamr is a
peer-to-peer network for real-time data streams. So my favorite one-liners
to explain Streamr to our technical audience,
which I assume this audience is, is that it's a decentralized
pub/sub [INAUDIBLE] program. We can also think of it
as a global decentralized time-series database. Or if you will, it's
a bit like BitTorrent but for real-time data streams
instead of static files. So basically, the data
source can publish messages to topics on the network. And they will
magically be delivered to all the subscribers
listening to that topic. And these interacting parties
could be like IoT devices in a smart city. They can be web
browsers using a dapp.

They can be Oracles seeking
to deliver that data to an on chain smart contract. Also, in the Streamr
ecosystem, there is a market place,
which is not a means to monetize the data
that is being produced. So if you're producing
something as valuable to others, you can put it up for sale. And we also have
a toolkit called Streamr cord, which is
actually being officially launched today. Yeah. [APPLAUSE] Thank you. Always good to ship things. That's the right toolkit
where you can easily create integrations. You can build analytics
and visualizations. You get your hands
dirty with data and manage stuff
in the same place.

So that's pretty
much the Streamr. Hi, I'm Andrew from CLC group. First, thanks to Johan
for hosting the panel. Thanks for Chainlink for
putting this together. It is nice to see
all the ecosystem members coming together. It consists of the
numbers coming, basically. CLC is a smart
contract lab that's built in specifically
for Chainlink. Right now, our main
product that's out is the Honeycomb marketplace. There, have together– I
think we have 15 up right now. But premium API providers
that are putting out their [INAUDIBLE]
most exciting data types, the ones that empower the use
cases that we'll be talking about for years and years now. We have sports data,
we have weather data, we have real world in terms
of financial [INAUDIBLE] data. We have API [INAUDIBLE]
things, like [INAUDIBLE] that's putting functionality
in your contracts. So [INAUDIBLE] for free
test calls, essentially doing marketplace
design for developers. We have testing portals
and a nice interface that makes it really
easy to integrate the table into the contracts– [INAUDIBLE] enter
your contracts.

And, once you're ready to
get everything to production, you then [INAUDIBLE] data
at a flat [INAUDIBLE].. So you can test for free. We can [INAUDIBLE] for free. We can't have folks call
the Vatican [INAUDIBLE],, things like that. But loose data points are free. And, from a business
development perspective, [INAUDIBLE] is that we've
got multiple data sources [INAUDIBLE] types of data. So you could get,
depending on the sport, multiple sports data providers
[INAUDIBLE] providers, so on and so forth, helping you
decentralize the API vendor is promising to the world. In addition to the
Honeycomb marketplace, we're also doing a few
[INAUDIBLE] products that lateralize the
staking system that's kind of registered
knowns [INAUDIBLE].. If you think that's entering
some civil resistance to the space, we [INAUDIBLE]. We're also working on a
security service for APIs.

I don't think I'm going to talk
too much about it just yet. But that's one. So our ultimate
goal is to sort of have a product or something
available for each component member of the ecosystem. And with the marketplace
that's out today, we really think we did
that for developers. We got rid of a lot
of the pain points that they're going to run into. Now they don't have to go
out and find data providers, find node operators that
can provide the data. And they don't have to deal
with all the legal stuff either. We've got all that covered. So all they have to do
is build the contracts. We're hoping to do that for
everybody else eventually too. So again, thanks to Johan. Thanks to the team. [INAUDIBLE] Hi, everyone. My name's Robert. And [INAUDIBLE]. Thanks to chainlink
for making this happen. It's great to be
able to [INAUDIBLE].. I'm working with the
kaiko We're a market data provider for financial market
and for the crypto market.

So for several years now, we
have been collecting, curating, and providing raw data,
aggregate derived data for crypto currency markets,
exchanges, [INAUDIBLE] providers. We're having a
historical data field, looking at historical data– web sockets or APIs mostly
targeted to investors and researchers in this space. But now it also
identifies [INAUDIBLE].. We also have started
working seriously with integrating
bringing market data to on chain smart contracts. The first initiative we
launched in production was with Chainlink. We're running our own
nodes as a node operator, and also as a market
data provider. So our whole query API with
all our data is exposed. You can do micro payments
transactions or calls, and get both the live and
historical data [INAUDIBLE].. And we're keeping a
close eye on what's happening in the
DeFi space we want to be able to accommodate all
the use cases that there are.

If you're building stuff in
market data for smart contracts and if your needs
aren't being met today, please come talk to us. It's always interesting to
see what people want to build and how they want to do it. Thank you. So I'm Trevor Clarke. I'm with And so we're actually
a data provider that covers a couple
different fronts. Similar to kaiko, we actually
do crypto currency markets as well as blockchain data. So we have a data pipeline
that's fairly flexible, where developers can connect
to our data pipeline and add all of the
features that we're looking for for
their applications without having to
run a full node or connect to multiple exchanges
and verify those transactions and match them up
with that market data.

So if you look at how
most people are building their applications,
you at some point need to send a transaction. And so what we did
is everything that we build for you runs a node. And you can sign
your transactions. You can have your
users not have to pay a fee or anything like that. You can send that to our API. You can have the full
context of market data. And then, on the filp
side, when you're serving your applications,
it's much faster. So our access via
RPC or web sockets or REST services,
all of that is just kind of one big package that
streamlines your application. Similar to Keiko, we have full
current and historical prices, like [INAUDIBLE] order books,
all of that available via web sockets as well. So I guess a
question we could ask is, this industry
is so new, right? There are a lot of gray
zones, regulatory-wise. So what kind of
legal issues have you encountered by providing
data to the blockchain? Who wants to go first.

[INAUDIBLE] Sure. One of the big things that
I think we've run into is that we want to be helping
people build the contracts that enable all the cool
DeFi applications, all of the cool derivatives and
insurance, but in many cases, the data providers
themselves are often a little anxious about that. They come to us
and say, we don't know who's going to
be using the data or what they're going
to be using it for. And of course in the
back of our heads, we're saying, well, that's
one of the cool things. But you can't say
that out loud, you've got to get them on board. So then we'll work with them
on these really onerous, know-your-customer requirements. Or, we're talking right now with
a lot of authorized resellers, and so that gives them a
little legal protection, but it also increases the price. And so all of these
solutions have their own kind of problems. Right now, if you want to
get a really top-tier data provider on board,
they need to know who the node operator
is, who the developer is, who the end user is.

And so now we have this
wonderful, elegant system that can do all these
cool new things, but they're in bits of
paper at every step, causing all this friction. And so I think
looking forward, one of the things we're really
going to need to figure out from a regulatory
standpoint is how to get some standards, how
to get some [INAUDIBLE] out of the way. Because it's really tough to
imagine smart contracts getting to the level of ubiquity
that I think a lot of us want to do if there's going
to be all these issues and all this regulation rolling
downhill onto the end user.

So right now, I'm
a really big fan of any organization working
on big, major, industry-wide standards. I think what the Accord
is doing is fantastic. I think some of the stuff
that Openlaw is doing is going to be really useful. And maybe we should
be thinking about that from a native provider
standpoint for smart contracts, if a couple of smart
contract data providers wanted to work together on
some standards for their [INAUDIBLE].

So more like technical
standards or standards on the license and the terms? I think they would go
hand-in-hand, very likely. But figuring out some things of
that, if the API providers are deciding they want
them, that's going to help some to get these
big names more comfortable and getting them on board. Because in many
ways, the blockchain is transparent also in who
has subscribed to [INAUDIBLE]..

You could have identity
services and all that. You could implement all
that with the blockchain. But of course, the question
is, what's the benefit there? I think we're going to
talk about privacy and user stuff a little bit
later, but, yeah, that is an issue that we're looking at. I could maybe add onto
that a little bit, just talking here from the
perspective of financial market data sets. That's what we're dealing with. What we've seen is
that there is not so much in terms of
the legal regulations, but there's a lot
of self-regulation from within the
financial sector. So when it comes to specifically
where we're working, we're like an intermediary data
provider, so we provide data, but we can [INAUDIBLE] data
from other data providers, essentially, the
sources of the data. When we're working with
mature crypto changes, we don't have that much
trouble, but there is usually a very pragmatic reason to
talk to and collaborate with.

But when we go to [INAUDIBLE] in
the space like index providers, companies like that, suddenly
you have a lot of bureaucracy and red tape and
things like that. And I think there's a
willingness from them. They want to provide data for
people like our customers, but they're also having
this internal frameworks and internal regulations that
they have to comply with. So I think this will be
solved both, as you say, from talking to each other and
trying to arrive at standards. And also, I think a
lot of these people aren't really aware of
exactly how things work. So you have to kind
of take the time to understand where
they're coming from and talk to them about
how can we align things so that it makes sense. And a lot of them want to
have strict control of how their data is disseminated. For us as soon as you
put the data point on our public blockchain,
it's out there in the public, and you have to
accommodate for that.

And I think that
will just be solved by talking to each other,
and it will work itself out. You said a lot of awesome stuff. Just to add on that,
from our integrations, a lot of their compliance
is their side of the wall. So what we've done is made
our APIs available to them. The way that they
access that data has to be compliant
with the access there. So we've just made that so that
it fits their model as well. I'm sure you guys have
done that as well. From our point of view,
the sort of legal hassles are a little bit
different as we're building a platform, which is an
open platform where anybody can put any kind of data on there. And we're sort of not
a party to transactions that happen in the ecosystem.

So if somebody buys
data, someone sells data, we're not a part of it in
the same way as you guys are. So the considerations for us are
more how do we enable adoption. How do we prevent our users
from stepping accidentally on some land mines
in this jungle that is the legal environment? And how to consider things
like GDPR, for example, in the case of personally
identifiable data. What are our
liabilities as creators of this technology, as opposed
to those who put it there? Let's say someone publishes some
illegal content, for example, on the Streamr network. Are we somehow liable for that? Maybe in the current
version, which is still partially centralized,
there's still an element of us as the creators of this system. But especially when it goes
to our full decentralization, how can this work from
a legal point of view? And this actually touches
on all decentralized systems and the current legal
frameworks such as GDPR doesn't consider
decentralized systems at all. It's clearly aimed
for the big giants who have several times been
caught abusing data and so on. So it's interesting to
see what the future holds.

For example, if I post a
transaction on Ethereum with, let's say, somebody's name
and address and phone number, that's personally
identifiable data. I don't think all the Ethereum
nodes are GDPR-compliant, so does that make
Ethereum illegal? Can I make Ethereum of illegal
by doing one transaction? Very interesting question. Awesome answers. So I guess this question is
more for CIC group and Streamr. So for API providers,
we are very used to having monthly subscriptions. You subscribe to an API
for a monthly basis, and you get [INAUDIBLE]
that you need, basically. You guys went with a
different pricing model, so maybe you could expand a bit
on what kind of pricing model you're using right now and
why you went this route.

Sure. So on the streaming
marketplace, we do have time-based
subscriptions, but it's not down to a specific
period like a month or a year. Instead, you can subscribe
for data for the period that you want so that
the price of data is basically defined
as price per time unit, like price per second. So you can buy it for an
hour or a week or a month or a year or 10 years
or whatever you want. And this creates flexibility. In the old world, writing
invoices and accepting credit card payments and settling
everything is a hurdle, but our blockchain
is sort of trivial, so you can very easily
create new kinds of patterns. Even ones that are based on,
let's say, data quantity, instead of the time. Which is a very
interesting prospect, but we went with the time-based
subscriptions for now, for two reasons. One, it's familiar to
people and data subscribers.

And two, it leads to
a fairly modest amount of on-chain transactions
that need to be made. If you buy a
product for a month, it will only do one
transaction per month. If it was based on
something else, that's might result in a lot of transactions
that would eventually be available in the
current-day blockchains. I think I'm one of
the things that's we really want to remember
when talking about how the APIs should be
per-call pricing through the smart
contracts-based world is that smart contracts
are not currently and probably never
will be, particularly high-volume or
high-call use cases.

Where a sports or weather app
needs thousands and thousands of calls a day to
stay up for a second with for their smart
contract instead execute one or two calls from
different nodes or completely different sources to find out
XYZ for a derivative or notes score the end of the game, we'll
know if it's raining or only at a certain time. Maybe the contract's
[INAUDIBLE] on Wednesday it should be bright. And so these are not
high-called use cases. And so with the API,
while it's built around trying to get as many
calls out there as possible, that's how they
make their money. So we're talking with these
financial data providers, and they ask us,
when are you going to get to a million calls? Chainlink has 140,000 calls
on the entire mainnet. That's been three months. I don't know if
Chainlink's going to get to a million
calls [INAUDIBLE] one financial data
provider through whatever percentage of the market
[INAUDIBLE] to get.

So we need to incentivize
some data to enter the space in a different way. You need to fundamentally
change the model, and that's what we've done. We are charging per call, and
a relatively higher per call, for a different set
of service priorities. The sort of standard that
we've seen across premium APIs providing data to the
Fortune 500 companies is 99.8% reliable. For some reason that's
the benchmark everybody loves to hear about. And for a currently
expensive system like a smart
contract, whose value is derived in part
by being reliable, 99.8% isn't going to cut it. So we're going to pay them
a little bit more money to give us greater
dependability and to make sure that they stay in the
space when they're not going to get the call
[INAUDIBLE] that they expected. So that's a lot of our
underpinning behind it. We started first thing with
that node operator perspective. The subscription model, the
freemium model that APIs [INAUDIBLE]– that won't encourage
the node operators that was going to [INAUDIBLE].

But after talking with
the API providers, walking through what the space
would look like anda how people would be using their
data, we collectively came to the decision that the
pricing model needed to change. And so that's why
we [INAUDIBLE].. So I guess that question is
more for data and [INAUDIBLE].. If you had to guess– or
maybe you have an estimate– how much of the
current nodes that are being brought to the APIs
are used by smart contracts, and how do you see this number
changing in the near future? So we actually look
at several blockchains so that we can see
those analytics overall. For us, we get a nice
breakdown from the network, where we can see individual
addresses plus contracts. So for us, if you went
to our dashboards today, it would show you
54% are contracts, and the rest of the network
was addresses itself. We're actually pretty new
to the Chainlink setup, so we're still watching
the Chainlink network analytics, which is really
exciting to see that grow.

From our perspective,
it's still pretty low. Compared to all contracts,
it's roughly less than 1%, so that's something
that we're, like, hey, let's see if we can
encourage that group there because we really
liked this interaction. And the amount of data that you
can get from a Chainlink Oracle contract is actually awesome. So if you aggregate those
prices historically, it now becomes something
like an aggregator contract that you can look at
back historically, which is something that
you can do and validate your logic over time. One of our core use
cases is people that are doing [INAUDIBLE] bots. And so they actually like to
run the historical data sets and then test their assumptions
and take that back on chain. And you can actually do that
now with the Oracle contracts.

I'm hoping to
create a marketplace for those aggregators
and those bots and the [INAUDIBLE]
numbers later. We have actually almost
close to zero actual usage of our Oracle's
nodes, and I think this may have something
to do with our profiling as a provider. We are marketing
a little bit more institutional and
enterprise-based. They're a bit more cautious. They're doubling down
on [INAUDIBLE] data filtering services. But we did get a lot of positive
feedback, when we announced that we're doing this. I think there's a lot
of interest in it. So it's definitely
going to grow. I think the whole space is
still in an exploratory phase, and then you read [INAUDIBLE]
would be from other people who are also in their [INAUDIBLE]. So I think this will be a little
mirror to how is this going to really start to take off. I think we came to the
exact same conclusion when it came to the pricing
models for our main services.

We have a license, [INAUDIBLE]. Whereas we also came
to the conclusion, this doesn't really make sense
for smart contracts, we think. So we're doing the
microtransactions there. But we are also going to
do other alternatives. We're going to evaluate
a subscription model, and we're going to see
what catches on, how are they using this in practice. So I think we have to give
different ways of using [INAUDIBLE] paid-for data to see
what the [INAUDIBLE] produces. All right, so if
anyone could tell us how the needs of smart
contract developers differ from, let's
say, web developers, the more traditional
developers we're used to. And how are you
catering to those needs? How are you electing
your system to make sure that they're happy using it? Sort of adding to
what was already said, for us, smart contracts are one
of the [INAUDIBLE] providers that data can have.

In addition to the stuff that
we're doing with Chainlink, which is sort of the
first step to create [INAUDIBLE] smart contracts. We also offers some tooling
for using that side of things in the stuff that we're
building ourselves. For example, the
[INAUDIBLE] Connect Data to smart contracts. But other than that, in our
experience, the smart contract developers are more or less
on their own in that sense. We try to hold their
hands and bring people into the ecosystem,
and we can sort of facilitate the discovery
of how you can build data-driven smart contracts. But as we've identified, it's
limited by certain factors. For example, the
scalability of blockchain, which should, in the
future, boost adoption of using smart contracts
as an application that is in a huge way. But it's a slow progress, right. I think right now, APIs
are built for speed and how quickly can
we get you calls, and how many calls
can we get you.

This almost doesn't
matter for smart contracts as much because in
their low calling use case, that might change
a little bit once you start to think about
trust execution environments and [INAUDIBLE]. But I still think the majority
of really high-value use cases that we're all excited
about, they're never going to be high called ones. And the speed doesn't matter
because right now Ethereum [INAUDIBLE] what smart contract
developers need instead is something else. They need dependence. And so one of the
things we try to do is negotiate particular
service level agreements with the providers. We have developers,
basically, to make sure that dependency will
be there and that they have what they need. As we mentioned before, I
think at least right now the users of smart
contracts tend to be a bit more ephemeral
than normal API users. It's difficult to be able to
with those restrictions on how data is going to be used
and make commitments of the usage [INAUDIBLE].

I think it's the
nature of people who develop smart
contracts-based system that they want to
be able to verify. For example, if they're
considering market data from us, they want
us to sign the data, and they also want
that signed data to view signature from
the data source itself. So they want to at
least have the ability to verify everything as far
back as the source [INAUDIBLE].. That also requires standards
for all the different service providers, upstream
providers, so that it can have this
possibility because you need to be actively engaged. Every purchaser has
to be able to do this. Can I get a quick show of hands. How many of you guys are
building applications on Ethereum or et cetera.

So this question was
about developers. For me, it's two things. One is that we all
want to meet you where you're at, which is
everything you normally use to interact with Ethereum– JSON RPC, normal REST calls,
web sockets, or however else it is needed to you,
we support that. So that's just the base level. The second level is education.

I think all us kind
of hinted at it, but it's really difficult to
interact in these new ways and learn about Chainlink and
learn about how you interact with these sectors,
so we focus a lot on the education of
how to actually connect to your contracts. If you looked at our blogs,
you can see most of them are tutorials. How do you actually execute X? Or I just published one
recently about all the things you can do with
Chainlink because there's lots of awesome ways you
can interact with it. Maybe a follow-up question
to you guys, if you will. You mentioned data
sign, so do you have data providers that
sign the data at the source, or is it more like you guys
are signing that halfway on its way to the subscriber? We're talking to our
upstream providers about it, but we haven't been able
to make it happen yet.

So right now it's
only signatures from our side, which doesn't
really mean that much. Frankly, what you
want to ensure is determine the actual
information that you're getting. We're just a proxy. If you can send a transaction,
then it has be presigned. I feel like we are quite lucky,
we have quite a lot of people, so we might just open up
the floor for some questions from the audience, if
that works for you guys? I was just going to say,
you guys [INAUDIBLE] operating on the [INAUDIBLE]? Right. So the question is, do you
guys see web assembling changing your operating model? Web assembly, like
everything else, we want to support because we're
just the data providers that wraps around current languages. So if you ran the web
assemblies and compiled them, something that
ultimately we will add support for those things so
that you interact in a way that you want to.

I think it's kind of like
asking us [INAUDIBLE] web assembly changing. [INAUDIBLE] structure
and [INAUDIBLE],, it's something [INAUDIBLE]. I guess from our point of
view, having [INAUDIBLE] can make it more efficient. But from our
perspective, it sort of improves the companion
chain, and not really much to Streamr itself. But I think also [INAUDIBLE]. [INAUDIBLE] Is the financial data in
the blockchain encrypted, or is it printed publicly
for everyone to read? Because if you want the
smart contract on the chain you're publishing it on
to be able to react to it, it has to be unencrypted.

That essentially means
that if anybody requests this thing that is going to
be using it, [INAUDIBLE].. Are you being
compensated to pass this data on to the blockchain? I think it is more, are we
compensating the provider properly [INAUDIBLE] right? If their cost associated
with [INAUDIBLE] for example, [INAUDIBLE] services. I think that's why there's
not a lot of people just streaming data
from blockchain. It can be wildly expensive. But in terms of
data and it becomes a public link once
it's on the blockchain, my CTO once described it as
certain data providers aren't selling data, they're
selling secrets. They have data that is more
up-to-date or more current, and so in selling it to us, they
are to a certain degree taking a risk.

Or if we have other providers,
ones we're in talks with right now, whose data set is just
updated once every two weeks or so. And hypothetically, if the
wrong user got his hands on it, they dump the data set,
and suddenly they're not in business anymore. There are some
problems with that, but we try to solve
them by working with regulators [INAUDIBLE]
and all that cool stuff. That was a good point. And I think another
element of that is going back to
what he said before about dependencies and
availability and reliability. So I'm sure if you
observe somebody else who made a smart
contract [INAUDIBLE] just the data points you're
interested in, you could [INAUDIBLE] to
that, but can you be sure that they will
be there tomorrow if you're building a production
system that's relying on this? And can you be
sure that they keep on serving the data that
your [INAUDIBLE] are doing? I think you're kind of inferring
what can I run as a business on top of this, if I
was a data provider.

For us, we actually
have it split. So we have a freemium model
for some of our API data, and so a lot of that is just
paying the regular Chainlink fee, which is likely
one [INAUDIBLE].. But then, if you configure
your adapter with your API key, since we're a
traditional SaaS model, the subscription fee
gives you the API key, and you can configure
that and have all the extra crazy aggregation
data that we provide as well. I don't know that there is a
way today that Chainlink could streamline all of that,
but you can actually do it a couple of different ways
so that the provider is also getting paid as well as
the network of Chainlink. Like I saw now that
of course the data points that the
smart contracts get have to be some
sort of aggregate, or they have to be
[INAUDIBLE] that anyway. With Streamr, the sort of
very premise of Streamr was it could build these
sort of aggregations with the Streamr
canvases, in which case you don't even need the
original of data points.

You can make a very
coarse aggregate of your smart contract needs
such as [INAUDIBLE] and then whoever wants to make further
use of that, they can try. So I don't know how much
in your basic models have you considered sort
of publishing aggregates kind of thing, or do you
actually publish the raw data to smart contracts? So the way we do it
is that we actually expose all our entire core
APIs available through our [INAUDIBLE] contract. But as part of the
request, you can also include aggregation
parameters, so the raw data will never send blockchain. You will get the
single data point, and you will specify
how the data point is derived from the [INAUDIBLE].

I think when the [INAUDIBLE] has
been vigilant about releasing the data. So it will never be
actually be published, it will be to a
coarse aggregate. Does that help with
the negotiation? So you mean that if the
data is freely aggregated? Yeah, what I mean is for when
the data producers are very jealous about their secrets. Is it an argument– could
you tell them, no, we are not actually going to
spoil all your secrets, only on a coarse
aggregate or something. You're not really losing much. I don't know. Is this even [INAUDIBLE]? So one side all our data. We don't expose [INAUDIBLE]
level orders, for example. You can get, for
instance, [INAUDIBLE].. It wouldn't really
make sense to– just like you were saying– it would be quite stupid to
try to get all the ticket level trades or
borders or something because the volume
is just so huge, it's going to cover up
the entire [INAUDIBLE] or it's going to cost
all the [INAUDIBLE] But it's more like,
probably, suppose there is some sort of logistic
tracking system or whatever, and then somebody would
just be interested in what one company, maybe
a competitor does.

So maybe that competitor
has elected [INAUDIBLE],, but they don't want to
tell it or whatever. I don't know. You could make it useful
even with one data point by seeing how quick your
computer does the achievements or whatever. The whole thing is
that there's always the level of how
you market the data. How you package it and
how somebody subscribes. And then there's the level
of how they actually use it, and of course they will never
actually use it in this market.

As you say, you cannot
put everything there. They will only ever use
some aggregate of it. So in some ways,
the data producers will never be losing
quite as much secrecy as the [INAUDIBLE] are. That's just what I'm saying. Is that something that
makes it easier for you, or is this not really
a talking point? If I could just add
one thing from that. You have the
different stakeholders with from a data
profiler's perspective, you have to trust the node
operators because they're doing degradation, so
your effectively exposing their identity to
the node operators. So there's kind of a
balance back there. Which position do you take? What level of trust and you've
looked into those brother and step-sister. I think, as you're
pointing out, [INAUDIBLE] problem is solved by the
fact that smart contracts are generally highly
[INAUDIBLE],, right? So Bloomberg can charge $30,000
for [INAUDIBLE] because they are selling you students
they [INAUDIBLE] the financial data
fractions [INAUDIBLE]..

With a smart contract, it's
gambling on an earnings report. You're not [INAUDIBLE]
your earnings report [INAUDIBLE] secret. You're often gambling
on [INAUDIBLE],, like, how big this
profits [INAUDIBLE].. Yeah. And if you could buy just,
if you could sort of say, you're giving me all
that $30,000 or whatever, but I'm going to
only ever promise you this one line,
that sort of thing. Again, I think
there's a need to have a full understanding of how
smart contracts work in order to take that step. That is one possible way
to sort of [INAUDIBLE].. They would be probably
much more willing to– you know, the smart
contract is something you can promise it always
works the same way. So perhaps the pricing should be
done not per the data packaging you're selling, but like,
this smart contract wants to use your data, what
is that contract price? Because you can
inspect the contract and see, oh, it's
only doing that thing, I'm only consuming that thing. And then you could price it
just for that contract, expense it that way. That sort of is
one way to do it. I think the better
one, though and what we've had more success
with is getting them on board with smart
contracts [INAUDIBLE]..

If they get that
2001 Space Odyssey moment where they realize what
a smart contract [INAUDIBLE] can look like and what it would
mean for them and their data, they're on board. So we could approach them and
sort of sell them job by job, but I think it's more effective
to try and give them the vision and do that educational process. Because if you do
that, navigating all these areas of friction
becomes infinitely easier. I have a question, too. [INAUDIBLE] So, you
mentioned earlier this educational
challenge [INAUDIBLE] It also seemed like
a sort of mind shift is happening in
various organizations to start [INAUDIBLE] new
kinds of data economies that can become possible. Could you elaborate a little
bit on what kind of change needs to happen? What are the things that
you finding organizations, both your data providers
and your customers comfortable with
channels and [INAUDIBLE]..

One of the things
we need to balance is that data providers often
come from the industries that their data represents. So a sports provider
is going [INAUDIBLE] professional football handler. A market provider's
going to be [INAUDIBLE].. And so while cryptomarkets
[INAUDIBLE] the provider, they're going to
[INAUDIBLE] this world. They know everything. But other providers,
while they'll technically be very smart and
[INAUDIBLE],, they're not necessarily [INAUDIBLE] to
understanding blockchain but [INAUDIBLE]. So the business development
part, the process is often a really
intensive vanguard. And when we reach into
that, I think we just remove it from its work. But to a certain
extent, it sounds like you're all doing it
[INAUDIBLE] because they're arguably the support
of our system.

If we don't get the data
providers into the space en masse, then what
are we going to do? So I think one technical
component that some [INAUDIBLE] concerns the data providers
have about their raw data being exposed and
protected [INAUDIBLE] trust execution environment. [INAUDIBLE] because that it can
remove a big part of the trust that these people don't know
operators and [INAUDIBLE].. So that they can do the
regulation that you were talking about without there
being these humans running the numbers being able to just
stash away and [INAUDIBLE] they cannot [INAUDIBLE]. Just going further on
the education side. Those that are working with DABS
have an onboarding problem, not just a data problem. And then we stack
everything in between. So it's not just about, hey,
we can provide you some data. It's also the why. Why do you want some of
that data to come into here and spark contracts, and then
how does the user actually interact with that? So that's the biggest thing
that we're trying to address.

If we want to actually
use outside data in a safe execution
of the blockchain, why would I want to do that? I want to keep everything
that I have in the blockchain and just do logic on that. So part of it is the education. If I'm, let's say
a trade station, and I want to get
my working data, I want to see all
the trades on chain, and I want to bring that into
what traditional investors are looking at, but I also want
to trust you on that, that's something that
takes a lot of steps forward in talks
with them or just allowing them to verify
that information. And also, how do they actually
integrate it into the apps that they're doing? That's what we're working on. Just to add a little,
the [INAUDIBLE] is that if you can sort of
lock them into that point, they get really excited.

They want the developers
there, so they can help promote the developers. They'll do what they can do. Whatever they can help get
done, they're willing to do it. They want to tweet about it. They want to help the
developers get up and get going, but you have to do that
extra work to get there. For us, an interesting
phenomenon I see is that we talk to
organizations where they're used to the business model,
where the most value for them comes out of keeping
the data in a silo, closing it up,
keeping it a secret. This new opportunity of
opening up a little bit and looking for those data
monetization opportunities, that's a scary new world
that not everybody wants to enter into.

While it can actually increase
the value of the [INAUDIBLE],, is this the device
manufacturers making [INAUDIBLE] garment factors,
or OEMs making parts, or [INAUDIBLE]. The factor is
everything, really. If they could optimize their
processors by exchanging data with each other, but
it's not happening because they are locked
down to this mindset, like, this is mine. Don't come close or I
might, sort of thing, and that's something
that using blockchain technology [INAUDIBLE]
technology could actually be disruptive to [INAUDIBLE]. I think you're touching
on a good point there.

One big hardship that we had was
to back [INAUDIBLE] start up, we treated data as a
commodity, basically. You pay us, and
we give you data. But realize that's
not really the value that in the
[INAUDIBLE] that they want the service of getting
the data or the license to use the data. So you start looking at
data not as a commodity, but you're looking at the
service you're providing or their rights to use
the debt in certain ways. It's not any more scary
that some of the data becomes public because
that's not your core value. Your IP is not consisting
of the data itself.

Let's play devil's
advocate for a second. If I was going to destroy
every data [INAUDIBLE] I go– or whoever else– I actually built
a little demo app just because I
wanted to test this. If I went in and took all the
raw data from our Chainlink connection, and I set that
up and built an aggregator, and I did aggregations
for order books, or if I did that
for [INAUDIBLE],, or if I did that for some of
my events for my contract. That actually was
extremely expensive, and then I was thinking,
what if we sharded, what if we didn't have
side channels, if we did state channels. It really doesn't quite
economically make sense because you're still missing
out on the fact of the uptime. You're also missing out
on that data recency. If I want to go collect
from multiple exchanges, or if I want to collect
from multiple blockchains, it's always going to be
the same latency issue.

So I think there's
still the need, and there always will be the
need, of the data provider, and you need to be
able to validate that that data provider actually
is giving you accurate data. I think that was really
good of the panel to discuss things like this. I think we have time
for one last question. Maybe to end, one last
question from me would be, what was the biggest
challenge you faced putting your
business, and how were you able to overcome it? I think we've touched on
many of the challenges, and roughly they are divided
into technical challenges, maybe legal challenges,
and, let's say, educational challenges.

I think there is major
ones in each of these, and it takes time, for sure. On the technical side,
the biggest challenge is to build a robust
transport system, for sure. How to create algorithms in a
network where basically anyone can participate, but
no one can [INAUDIBLE] in a sense of building the
incentive mechanisms, which we're only early
days on that part. And how to verify things. If we have a new network
of thousands of nodes, how will that behave? What about millions of nodes? Where does it end,
where does it break? have That kind of thing. From the legal side, for
sure, one of the early issues was just getting the fundraising
done, but that was like 2017, but perhaps could be mentioned
as one of the biggest challenges. It was very unestablished
at the time– still is– and it maybe hasn't even
gotten easier in two years. At the moment maybe
on the legal side, it's more about
considering general PR, considering how users can
use this safely for building, tooling, for
creating data unions.

Basically which means that
a large group of people can come together– maybe they're owners
of a particular device like a Fitbit or a
Tesla, or whatever– and they can pull
data into a product and then sell that
to people interested and get compensated for it. So basically, end users
to earn with the data that are producing. But this is extremely complex
from a legal point of view because there's so
many participants. It depends on what
kind of data it is. Health data is more strictly
regulated than some machine data like a sensor measuring
temperature, humidity or whatever. So this is something we're
trying to build a framework for so that people developing
these applications can sort of get an app out-of-the-box
template for the legal framework for their application
and fill in the blanks and then go with that.

And on the education side, as
you guys mentioned as well, there's various mind shifts that
need to happen on all levels. Also onboarding developers
and making that part easy, but also in the
big organizations to start to change
the way that they are used to operating and
hoarding that value versus participating in
a more open ecosystem and making data more available. I think for us, and maybe
a lot of new startups face a similar
situation, we were trying to do all this
business development, all this education. Selling providers on this new
model and getting all this done when it was just
unicorns and fairies. It was all a
hypothetical marketplace that we were discussing
on behalf of [INAUDIBLE].. Now that the thing is
actually up and running, now that we have this
thing [INAUDIBLE],, now that we've built a tool
that developers can use, we've done the thing.

Things are going to start
going a lot quicker for us. We've got some exciting
things coming up. If we just look on a
very practical level what are the most difficult
challenges for us on a day-to-day
basis, I think it consists of the
main problem that is the number of customers
[INAUDIBLE] use us for, and that is solving
fragmentization. What I mean by that
is if you look at how from the sources
of cryptochanges, there is no standard
nomenclature. For example, there's two
tokens, both 1 USD coins, and there are
different stable coins around the same value of $1. And different exchanges
will have different coins that equal a USD coin. And some of them will
use the same [INAUDIBLE] for different currencies. You also have undocumented
differences in semantics and API and stuff like that. I think this class of
fragmentizations in a broader sense is the biggest challenge
for the [INAUDIBLE] community and the blockchain
space in general. If we could layer
two solutions, I think we have more layer
2 solutions than we have people who want to use
layer 2 solutions today.

I think we need
to seriously start to talk about forming
standards policy. How do we talk about
this [INAUDIBLE]?? How do we name them? And can we agree on
Google protocols? Just look at things
like F 2.0 working out. We have an
agreed-upon way of how we solve consensus [INAUDIBLE]. But how the clients talk to each
other, like network protocol, that's something that
we're only starting to look at now through
just the developers talking to each other. But I think this needs to
be formalized a little bit. And I know that
in this space, we like to hold formalization
of stuff at an arm's length, but I think it's
really necessary to be able to make something
useful and [INAUDIBLE] thing and interoperability property. Yeah, it's definitely
difficult. Just to answer what you're
saying, they're definitely heads-down on that
spec, and they're still working on that, a lot
of the chats with them. I think the real issue is
that the government is not pushing funding for it and
finding those folks that are talented to clear that
spec, and there's no one really taking the charge to do that.

But to go back to your
original question, what are the challenges
for [INAUDIBLE] data? A lot of it is making sure
that we have all the data available, easy to access. All of the data
that we do collect from different exchanges and
from different blockchains, that it's all verifiable. So the challenges with
exchanges with, let's say, non-decentralized
providers, is how do we validate their actual
volume and all that stuff? So for us it's a lot of
providing that context for all the developers
and for the end users, making sure that it's
good and sound data. I'm just curious, what's your
stance on verifying volume, for example? For us, we look at all of the
order books and all the trades, and if we can marry those
two blockchain transactions, that's something that we
can actually validate.

For the things that
are just reported, this is probably an
awesome feature idea, but maybe just
signifying, hey, this is what the exchange recorded. Versus, this is
something that we can nail back down to our chain. Since we provide
both of those things, it's up to the apps of the
developers to make sure that they're actually recording
the real volume to their users, but I'm sure that's something
that you guys have encountered as well. Yes. But centralized
change is difficult.

You could have one Bitcoin
being transferred and then that Bitcoin being traded back
and forth a million times. How do you know that all of
those are not [INAUDIBLE]?? It's a tricky question. You have very sophisticated
research papers that are trying to solve this,
but it's kind of an oxymoron. You can only make
statistical guesses. Awesome. I think that was
the last question, so thank you, everyone. This was an awesome discussion. Don't hesitate to stick around. We have some really nice
events coming up also. And thanks again
to the speakers. It was really a great time. Thanks for moderating, and
thanks for inviting us. Thank you.

You May Also Like