-
https://t.me/OriusVentureFunds www.ovf.info
https://www.facebook.com/OriusVentureFunds
https://twitter.com/OriusVFs
Version 2.8
ORIUS VENTURE FOUNDATIONWHITEPAPER
www.ovf.info
-
02
MARKET OVERVIEW & BLOCKCHAIN SOLUTION I. THE (SAD)
STATE-OF-THE-ART II. RESEARCH ACHIEVEMENTS
DISCLAIMERS I. IMPORTANT INFORMATION II. DISCLAIMER OF LIABILITY
III. NO REPRESENTATIONS OR WARRANTIES IV. REPRESENTATIONS AND
WARRANTIES BY YOU V. CAUTIONARY NOTE ON FORWARD-LOOKING STATEMENTS
VI. THIRD-PARTY INFORMATION AND NO CONSENT OF OTHER PERSONS VII.
TERMS USED VIII. NO ADVICE IX. NO FURTHER INFORMATION OR UPDATE X.
RESTRICTIONS ON DISTRIBUTION AND DISSEMINATION XI. NO OFFER OF
INVESTMENT OR REGISTRATION XII. RISKS AND UNCERTAINTIES XIII. RISKS
RELATING TO THE RECEIVING ADDRESS AND WALLETS XIV. RISKS RELATING
TO THE ISSUER
PROJECT TEAM
OVF TOKEN
I. VALUE PROPOSITION OF OVF TOKEN II. ROADMAP
OVF & ECOSYSTEM I. TOWARD DECENTRALIZED MARKETPLACES II.
SCALING BLOCKCHAINS III. THE NATIVE TOKEN IV. A DECENTRALISED
MARKETPLACE FOR OUTSOURCED COMPUTATION V. SMART-CONTRACT POWERED
TOURISM-INSURANCE
-
* https://www.comp.nus.edu.sg/~hungdang/papers/sharding.pdf
MARKET OVERVIEW & BLOCKCHAIN SOLUTION
03
I. THE (SAD) STATE-OF-THE-ART
Today’s economy heavily relies on brokers.
A broker is essentially responsible for arranging transactions
between a buyer and a seller for a certain commission when the deal
is executed. Such transactions may range from real-estate, to
lodging, insurance, or other financial services. This, beyond any
doubt, brings unprecedented convenience and accessibility to both
buyers and sellers.
The key necessary prerequisite of the aforementioned brokering
is the trust that relevant parties have to place in the broker. In
particular, the broker should be trusted to conduct the deal in a
transparent and fair manner.
This delicately subtle premise, unfortunately, is often
overlooked, which inadvertently makes either the buyer or the
seller, or even both of them, to likely fall prey to a bureaucratic
nightmare and widespread fraud.
Under the current systems, the relevant parties have little
choice but to rely on legislations and governmental regulations to
keep the brokers in check. Nonetheless, one still needs to rely on
a third party to enforce such legislations and governmental
regulations , which does not address the trustworthiness issue. One
often has to be the victim before the relevant authorities step up,
by which time, it is usually too late.
The Blockchain (or distributed ledger) technology, armed with
its great promise of transpar-ency and security, has come to the
rescue.
In a nutshell, the blockchain allows one to record and manage
transactions in a transparent, decentralized and immutable manner.
Furthermore, blockchain technology also enables a smart contract,
which is an autonomous agent incorporating a predefined set of
operations or logic that is to be performed on transaction
data.
In other words, with blockchain technology, one no longer has to
trust a third party to carry out a transaction on one’s behalf, and
one is also assured that once the said transaction has been
executed, it is transparent, objective and conclusive.
Nevertheless, there remains a hindrance that deters a wide
adoption of blockchain tech-nology in our everyday life, which is
its limited scalability.
While conventional centralized brokers like VISA and Paypal are
able to process thousands of transactions per second (tps) (e.g.,
typical workload of Visa stands at 2,000-4,000 tps)*, current
general-purpose blockchain platform, (i.e., supporting use cases
beyond crypto-cur-rencies) are only able to handle one tenth to one
hundredth, of such a load (e.g., Ethereum network’s throughput is
about 10-15 tps)*.
-
MARKET OVERVIEW & BLOCKCHAIN SOLUTION
04
-
MARKET OVERVIEW & BLOCKCHAIN SOLUTION
05
II. RESEARCH ACHIEVEMENTS
The Core Technology that empowers the OVF token is engineered
based on the research work that the CTO, Dr Hung Dang does in the
capacity as Research Fellow at the NUS Centre for Research in
Private Technologies (N-CRiPT). Belows are some of the extracts of
his research and the list of Research achievements that he has
done.
• Autonomous Membership Service for Enclave Applications Hung
Dang, Ee-Chien Chang arXiv:1905.06460, May 2019 • Towards Scaling
Blockchain Systems via Sharding
Hung Dang, Anh Dinh, Dumitrel Loghin, Ee-Chien Chang, Qian Lin,
Beng Chin Ooi ACM SIGMOD International Conference on Management of
Data (SIGMOD 2019) • Towards a Marketplace for Secure Outsourced
Computations
Hung Dang, Dat Le Tien, Ee-Chien Chang European Symposium on
Research in Computer Security (ESORICS 2019) • Flipped-Adversarial
AutoEncoders
Jiyi Zhang, Hung Dang, Hwee Kuan Lee, Ee-Chien Chang
arXiv:1802.04504, February 2018 • Evading Classifiers by Morphing
in the Dark Hung Dang, Yue Huang, Ee-Chien Chang ACM Conference on
Computer and Communications Security (CCS 2017)
• Privacy-Preserving Data Deduplication on Trusted
Processors
Hung Dang, Ee-Chien Chang IEEE International Conference on Cloud
Computing (IEEE CLOUD 2017)
• Privacy-Preserving Computation with Trusted Computing via
Scramble-then-Compute Hung Dang, Tien Tuan Anh Dinh, Ee-Chien
Chang, Beng Chin Ooi Privacy Enhancing Technologies Symposium (PETS
2017)
• Proofs of Data Residency: Checking whether Your Cloud Files
Have Been Relocated
Hung Dang, Erick Purwanto, Ee-Chien Chang ACM Asia Conference on
Computer and Communications Security (ASIACCS 2017)
• Practical and Scalable Sharing of Encrypted Data in Cloud
Storage with Key Aggregation
Hung Dang, Yun Long Chong, Francois Brun, Ee-Chien Chang
Information Hiding and Multimedia Security (IH&MMSEC 2016) •
PrAd: Enabling Privacy-Aware Location based Advertising
Hung Dang, Ee-Chien Chang Workshop on Privacy in Geographic
Information Collection and Analysis (GeoPrivacy 2015)
• Auto-Patching DOM-Based XSS At Scale Inian Parameshwaran,
Enrico Budianto, Shweta Shinde, Hung Dang, Atul Sadhu and Prateek
Saxena ACM SIGSOFT Symposium on the Foundations of Software
Engineering (FSE 2015) • Maximum Complex Task Assignment: Towards
Tasks Correlation in Spatial Crowdsourcing Hung Dang, Tuan Nguyen,
Hien To International Conference on Information Integration and
Web-based Applications & Services (iiWAS 2013)
-
II. RESEARCH ACHIEVEMENTS
The Core Technology that empowers the OVF token is engineered
based on the research work that the CTO, Dr Hung Dang does in the
capacity as Research Fellow at the NUS Centre for Research in
Private Technologies (N-CRiPT). Belows are some of the extracts of
his research and the list of Research achievements that he has
done.
• Autonomous Membership Service for Enclave Applications Hung
Dang, Ee-Chien Chang arXiv:1905.06460, May 2019 • Towards Scaling
Blockchain Systems via Sharding
Hung Dang, Anh Dinh, Dumitrel Loghin, Ee-Chien Chang, Qian Lin,
Beng Chin Ooi ACM SIGMOD International Conference on Management of
Data (SIGMOD 2019) • Towards a Marketplace for Secure Outsourced
Computations
Hung Dang, Dat Le Tien, Ee-Chien Chang European Symposium on
Research in Computer Security (ESORICS 2019) • Flipped-Adversarial
AutoEncoders
Jiyi Zhang, Hung Dang, Hwee Kuan Lee, Ee-Chien Chang
arXiv:1802.04504, February 2018 • Evading Classifiers by Morphing
in the Dark Hung Dang, Yue Huang, Ee-Chien Chang ACM Conference on
Computer and Communications Security (CCS 2017)
• Privacy-Preserving Data Deduplication on Trusted
Processors
Hung Dang, Ee-Chien Chang IEEE International Conference on Cloud
Computing (IEEE CLOUD 2017)
• Privacy-Preserving Computation with Trusted Computing via
Scramble-then-Compute Hung Dang, Tien Tuan Anh Dinh, Ee-Chien
Chang, Beng Chin Ooi Privacy Enhancing Technologies Symposium (PETS
2017)
• Proofs of Data Residency: Checking whether Your Cloud Files
Have Been Relocated
Hung Dang, Erick Purwanto, Ee-Chien Chang ACM Asia Conference on
Computer and Communications Security (ASIACCS 2017)
MARKET OVERVIEW & BLOCKCHAIN SOLUTION
06
• Practical and Scalable Sharing of Encrypted Data in Cloud
Storage with Key Aggregation
Hung Dang, Yun Long Chong, Francois Brun, Ee-Chien Chang
Information Hiding and Multimedia Security (IH&MMSEC 2016) •
PrAd: Enabling Privacy-Aware Location based Advertising
Hung Dang, Ee-Chien Chang Workshop on Privacy in Geographic
Information Collection and Analysis (GeoPrivacy 2015)
• Auto-Patching DOM-Based XSS At Scale Inian Parameshwaran,
Enrico Budianto, Shweta Shinde, Hung Dang, Atul Sadhu and Prateek
Saxena ACM SIGSOFT Symposium on the Foundations of Software
Engineering (FSE 2015) • Maximum Complex Task Assignment: Towards
Tasks Correlation in Spatial Crowdsourcing Hung Dang, Tuan Nguyen,
Hien To International Conference on Information Integration and
Web-based Applications & Services (iiWAS 2013)
-
www.ovf.info
V. SMART-CONTRACT POWERED TOURISM-INSURANCE Tourism-insurance
have always been a lucrative industry sector. An insurance contract
is typi-cally held between the insurer and the policyholder,
wherein the latter makes an initial pay-ment, or premium, to the
former in exchange for a promise that the insurer will cover the
loss that the insured suffer in case of travel inconvenience or
unexpected incidents. The essence of such an insurance contract can
be deemed as a set of “if then ”. Nonetheless, these conditions are
often intentionally defined vaguely by the insurer in order to
maximize their profit. At the same time, policyholders may attempt
to perform fake claims, lie, and cheat to get the payout. That is,
an ill-managed insurance system will leave both sides unhappy with
each other or even lead to court litigation. There remains a
significant avenue for improvement in the tourism-insurance
industry, and smart contracts, armed with its special properties,
including transparency, autonomy and accuracy, are poised to do
just that. By leveraging smart contracts, both insurer and
policy-holder are able to manage premium and settle claims in a
transparent and accountable manner. In particular, the contract
policy can be recorded and verified on the blockchain’s
tamper-proof ledger. Upon a claim being submitted, the blockchain
ensures that only valid claims are indemnified, and
settlement/payment of the claim is conducted in a fair and
autonomous fashion. In particular, a policyholder cannot submit
multiple claims for the same incident, and the insurer cannot pay a
compensation that is lower than what the policyholder is rightfully
entitled to.
While constructing an insurance system leveraging blockchain and
smart contracts appears rather intuitive, avid readers should have
realised a subtlety that is easily overlooked, which is, in order
for the system to operate, the smart contract requires trustworthy
data feeds (aka oracles) for access to data about real-world state
and events. Unfortunately, an ecosys-tem of trustworthy data feeds
is yet to be realised, which is a critical obstacle to the wide
adoption of smart contracts as financial instruments. We envision
to sidestep this problem by building an authenticated data feed for
smart con-tracts system, taking advantage of Intel SGX’s trusted
execution environment to ensure security. In a nutshell, the
authenticated data feed essentially acts as a bridged between
HTTPS-enabled data websites and the smart contract of the
blockchain. More specifically, the SGX-empowered authenticated data
feed pulls data about real-world state and events from recognised
and trustworthy HTTPS-enabled data websites, and relay them to the
smart contract in such a way that the integrity and authenticity of
the data source are preserved. This is achieved by executing the
core functionality of the authenticated data feed as a trust-ed
piece of code inside an SGX enclave, thereby protecting against
malicious adversaries that wish to tamper with its execution.
Figure 5: smartcontract-empowered insurance
OVF & ECOSYSTEM
07
I. TOWARD DECENTRALIZED MARKETPLACES
Our vision is to bring transparency, security, and convenience
to a broad host of transaction-al services and financial services
using blockchain technology.
A great many of today’s digital marketplaces, for instances
insurance-tourism and cloud com-puting, can be facilitated and
benefit from blockchain technology, if only such blockchain
technology can be scaled!
Based on OVF CTO’s ground-breaking research, OVF intends to
build a performative, high-throughput blockchain platform that
supports general-purpose workloads, and then codify the service’s
logic into autonomous smart contracts running on the OVF blockchain
which will enshrine the blockchain advantage of security and
transparency but with a very high transaction throughput (“OVF
Platform”).
Figure 1: Smart Contract vis-a-vis traditional contract
II. SCALING BLOCKCHAINS
Designing a performative and general-purpose blockchain system
has proven to be a challenging feat, as demonstrated by the
limitations of existing blockchain platform. For example: -
Ethereum suffers from low throughput, - EOS lacks decentralization,
- Zilliqa faces difficulties in handling generic transactions, and
the list goes on.
Resolving these challenges are daunting for various reasons.
Firstly, the adversary has excel-lent economic incentives to
deviate from its expected behaviours with respect to the
block-chain protocol, due to the very nature of financial services
built on top of the blockchain. Sec-ondly, that miners, which are
nodes that participates in maintaining and securing the block-chain
states, are typically distributed across the world, complicates and
affects transaction speed as the communication between nodesmay not
be synchronous. Thirdly, the sheer number of participants, the lack
of an inherent Public-Key Infrastructure, the very nature of
decentralization altogether, and Sybil attack.
Interestingly, one can solve a puzzle of the present by looking
far enough into the past. In this spirit, we systematically revisit
the data management and distributed computing litera-ture and make
a critical observation that blockchain is ultimately a distributed
ledger that commands security in the face of the Byzantine
adversary. This observation is essentially a bridge that connects
the blockchain puzzle to several decades of extensive and
well-studied research in the domain of distributed data management.
In that realm, sharding is a promi-nent and proven technique to
scale-out databases.
In a nutshell, sharding divides the database into smaller
components, called “shards”, and let each shard be managed by a
somewhat independent subset of nodes.
By distributing workloads among the shards and simultaneously
executing them in a coordi-nated manner, we can scale the
transaction throughput alongside with the network size, thereby
improving transaction throughput. However, extending sharding to
blockchain systems is no simple feat, due to the fundamental
difference in failure models between databases and blockchain. The
former assumes crash-failures, whereas the latter guards against
Byzantine failures.
Figure 2: Sharding the Blockchain
Our paradigm leverages on Intel SGX’s enclave execution to
enable confidentiality and integ-rity protection of clients’ inputs
and outsourced computation. Abstractly, the trusted execu-tion
environment (TEE) provisioned by SGX, called an enclave, prevents
other applications, the operating system and even the host owner of
the compute node from tampering with the execution of application
loaded within or observing its state, thus guaranteeing data
confidentiality and computation integrity. More specifically, Intel
SGX is a set of CPU exten-sions capable of providing
hardware-protected enclave for generic computations. It enables a
host to instantiate multiple enclaves at the same time. An enclave
is isolated from other enclaves, from the operating system (OS),
and from the host itself. Each enclave is associated with a
protected address space. The trusted processor blocks any
non-enclave code’s attempt to access the enclave memory. Memory
pages can be swapped out of the enclave memory, but it is encrypted
using the processor’s key prior to leaving the enclave. Moreover,
Intel SGX provides attestation mechanisms that allows an attesting
enclave to demonstrate to a validator that it has been properly
instantiated with the correct code. In addition, the attestation
mechanism also enables the attesting enclave and the validator to
establish a secure, authenticated channel via which they can
securely communicate sensitive data.
To enable fair exchange between the clients and compute nodes,
we intend to design a novel hybrid architecture that combines
enclave-based metering with blockchain micropayment channel. More
specifically, the OVF Platform intends to incorporate in each
enclave that houses the outsourced computation an accounting logic
that correctly meters the compute node’s work. Such metering is
then translated to a payment promise with which the compute node
can settle the escrow and claim the corresponding reward. This
should allow the fair exchange between the client’s payment and the
compute node’s work in executing the out-sourced task, without
incurring high overhead (i.e., transaction fee) or involving a
trusted third party
Figure 4: Transactions in our Decentralized Computation
Marketplace
We intend to overcome the limitations of existing blockchain
platforms by taking a princi-pled approach that adapts sharding to
Byzantine failure model of blockchain systems, and in doing so,
improve their transaction throughputs at scale. Put differently, as
the number of participants in the OVF Platform grows, so does its
throughput capacity. At a high level, sharding technique still
divides the blockchain network into smaller committees uniformly at
random. To ensure the security of the committee formation, an
unbiased distributed randomness generating protocol needs to be
designed, leveraging recent enclave execution primitives of modern
CPUs (e.g., Intel Skylake proces-sors) to improve the protocol’s
latency. Unlike traditional sharding in the database, it is
intended that each committee in the OVF blockchain system runs an
optimized Byzantine fault-tolerant (BFT) consensus protocol to
ensure their safety, instead of a crash failure tolerant
replication protocol.
Another difference with the traditional database is that the
coordination of cross-shard transactions (i.e., transaction that
affects the state of multiple committees at once) in our envisaged
sharded blockchain is Byzantine-fault tolerant and non-blocking,
which are essen-tial to guarantee consistency of the complex and
distributed transactions.
It is also worth mentioning that we intend the OVF Platform to
support autonomous smart contract with general workloads and
applications that go beyond crypto-currency. Via these smart
contracts, we can anchor various services and marketplaces on top
of the OVF Plat-form, offering them both security and performance
at the same time. The prototype attains a transaction throughput
rivalling that of Visa while enjoying decentralization and high
level of Byzantine fault-tolerance and security. Given our CTO’s
capability of delivering technological advancement, especially the
envis-aged high transactional speed of the OVF Platform, we expect
to be in a unique position to work with other technology companies
s to integrate OVF Platform’s core technical compe-tencies into
their systems, and in doing so, allow them to scale.
We will evaluate and select technology start-ups to incubate
using OVF Tokens and on-board such start-ups onto OVF Platform. In
return, we intend to, in compliance with all applicable laws and
within the concept of OVF Tokens being an utility token, to enter
into arrangements with such start-ups that we incubate to commit an
agreed percentage of their revenue or profit to purchase OVF
Tokens. This will create a demand, circulation and liquidity for
OVF Tokens with the ecosystem.
III. THE NATIVE TOKEN Besides security and performance, one key
component of any service and/or marketplace is a “currency” (or a
token system) that is used to facilitate payments. Such a currency
should be implemented on the blockchain (i.e., native to the
blockchain), to ease the logic and work-flow of the smart contracts
implemented for the services/marketplaces. We therefore intend to
build a token based on our envisaged OVF blockchain (“OVF
Token”).
Fortunately, after the OVF blockchain is created, a token system
is surprisingly easy to imple-
ment on the anticipated OVF blockchain, as it is going to be
fundamentally a database with one operation: subtract X units from
one debit account and gives X units to a credit account, provided
of course that the debit account has sufficient balance to
accommodate the opera-tion, and it is authenticated by the debit
account’s owner
The core issue of blockchain technology not being able to be
scaled due to the lack in trans-actional speed is expected to be
overcome by our intended core scaling technology. This would allow
the OVF Platform to be integrated into the various commonly owned
technolog-ical start-ups’ ecosystems. In the following, we discuss
two particular practical examples where the logic and/or the
operations of the broker/service provider can be implemented in
smart contracts on the OVF Platform, thereby offering both security
(i.e., no single point of failure) and high transaction
throughput.
IV. A DECENTRALISED MARKETPLACE FOR OUTSOURCED COMPUTATION
The cloud computing paradigm offers its clients convenient and
on-demand access to a shared pool of computing resources, enabling
the latter to provide scalable services with minimal management
effort. Nonetheless, it is worth noting that all such conveniences
are offered by and at the discretion of a few specific service
providers. This has raised various security con-cerns. We aim to
disrupt this status quo by introducing a fair marketplace for
secure outsourced computations. In particular, our envisaged novel
cloud computing paradigm aggre-gates computational resources
provisioned by a large cohort of independent compute nodes, and
offer them to end-users. Moreover, our envisaged framework is
intended to be capable of protecting the confidentiality of
clients’ inputs and the integrity of the outsourced computa-tion,
as well as mediating exchanges between the clients’ payments and
the compute nodes’ work in servicing the clients’ requests without
relying on a trusted third party.
Figure 3: Decentralized Marketplace for Outsourced
Computation
SILLY CONTRACT SMART CONTRACT
- BORING OFFICIAL PAPER- NO GUARANTEE- KILL THE TREES- NEEDS 50
LAWYERS
- PERFECT CODE- VERIFIED BY MATHS- I’M A PROGRAMER YOU CAN’T
FOOL ME- ANYONE CAN WRITE HIS OWN
NOT YOUR BUDDY YOUR BUDDY
-
V. SMART-CONTRACT POWERED TOURISM-INSURANCE Tourism-insurance
have always been a lucrative industry sector. An insurance contract
is typi-cally held between the insurer and the policyholder,
wherein the latter makes an initial pay-ment, or premium, to the
former in exchange for a promise that the insurer will cover the
loss that the insured suffer in case of travel inconvenience or
unexpected incidents. The essence of such an insurance contract can
be deemed as a set of “if then ”. Nonetheless, these conditions are
often intentionally defined vaguely by the insurer in order to
maximize their profit. At the same time, policyholders may attempt
to perform fake claims, lie, and cheat to get the payout. That is,
an ill-managed insurance system will leave both sides unhappy with
each other or even lead to court litigation. There remains a
significant avenue for improvement in the tourism-insurance
industry, and smart contracts, armed with its special properties,
including transparency, autonomy and accuracy, are poised to do
just that. By leveraging smart contracts, both insurer and
policy-holder are able to manage premium and settle claims in a
transparent and accountable manner. In particular, the contract
policy can be recorded and verified on the blockchain’s
tamper-proof ledger. Upon a claim being submitted, the blockchain
ensures that only valid claims are indemnified, and
settlement/payment of the claim is conducted in a fair and
autonomous fashion. In particular, a policyholder cannot submit
multiple claims for the same incident, and the insurer cannot pay a
compensation that is lower than what the policyholder is rightfully
entitled to.
While constructing an insurance system leveraging blockchain and
smart contracts appears rather intuitive, avid readers should have
realised a subtlety that is easily overlooked, which is, in order
for the system to operate, the smart contract requires trustworthy
data feeds (aka oracles) for access to data about real-world state
and events. Unfortunately, an ecosys-tem of trustworthy data feeds
is yet to be realised, which is a critical obstacle to the wide
adoption of smart contracts as financial instruments. We envision
to sidestep this problem by building an authenticated data feed for
smart con-tracts system, taking advantage of Intel SGX’s trusted
execution environment to ensure security. In a nutshell, the
authenticated data feed essentially acts as a bridged between
HTTPS-enabled data websites and the smart contract of the
blockchain. More specifically, the SGX-empowered authenticated data
feed pulls data about real-world state and events from recognised
and trustworthy HTTPS-enabled data websites, and relay them to the
smart contract in such a way that the integrity and authenticity of
the data source are preserved. This is achieved by executing the
core functionality of the authenticated data feed as a trust-ed
piece of code inside an SGX enclave, thereby protecting against
malicious adversaries that wish to tamper with its execution.
Figure 5: smartcontract-empowered insurance
I. TOWARD DECENTRALIZED MARKETPLACES
Our vision is to bring transparency, security, and convenience
to a broad host of transaction-al services and financial services
using blockchain technology.
A great many of today’s digital marketplaces, for instances
insurance-tourism and cloud com-puting, can be facilitated and
benefit from blockchain technology, if only such blockchain
technology can be scaled!
Based on OVF CTO’s ground-breaking research, OVF intends to
build a performative, high-throughput blockchain platform that
supports general-purpose workloads, and then codify the service’s
logic into autonomous smart contracts running on the OVF blockchain
which will enshrine the blockchain advantage of security and
transparency but with a very high transaction throughput (“OVF
Platform”).
Figure 1: Smart Contract vis-a-vis traditional contract
II. SCALING BLOCKCHAINS
Designing a performative and general-purpose blockchain system
has proven to be a challenging feat, as demonstrated by the
limitations of existing blockchain platform. For example: -
Ethereum suffers from low throughput, - EOS lacks decentralization,
- Zilliqa faces difficulties in handling generic transactions, and
the list goes on.
OVF & ECOSYSTEM
08
Resolving these challenges are daunting for various reasons.
Firstly, the adversary has excel-lent economic incentives to
deviate from its expected behaviours with respect to the
block-chain protocol, due to the very nature of financial services
built on top of the blockchain. Sec-ondly, that miners, which are
nodes that participates in maintaining and securing the block-chain
states, are typically distributed across the world, complicates and
affects transaction speed as the communication between nodesmay not
be synchronous. Thirdly, the sheer number of participants, the lack
of an inherent Public-Key Infrastructure, the very nature of
decentralization altogether, and Sybil attack.
Interestingly, one can solve a puzzle of the present by looking
far enough into the past. In this spirit, we systematically revisit
the data management and distributed computing litera-ture and make
a critical observation that blockchain is ultimately a distributed
ledger that commands security in the face of the Byzantine
adversary. This observation is essentially a bridge that connects
the blockchain puzzle to several decades of extensive and
well-studied research in the domain of distributed data management.
In that realm, sharding is a promi-nent and proven technique to
scale-out databases.
In a nutshell, sharding divides the database into smaller
components, called “shards”, and let each shard be managed by a
somewhat independent subset of nodes.
By distributing workloads among the shards and simultaneously
executing them in a coordi-nated manner, we can scale the
transaction throughput alongside with the network size, thereby
improving transaction throughput. However, extending sharding to
blockchain systems is no simple feat, due to the fundamental
difference in failure models between databases and blockchain. The
former assumes crash-failures, whereas the latter guards against
Byzantine failures.
Figure 2: Sharding the Blockchain
Our paradigm leverages on Intel SGX’s enclave execution to
enable confidentiality and integ-rity protection of clients’ inputs
and outsourced computation. Abstractly, the trusted execu-tion
environment (TEE) provisioned by SGX, called an enclave, prevents
other applications, the operating system and even the host owner of
the compute node from tampering with the execution of application
loaded within or observing its state, thus guaranteeing data
confidentiality and computation integrity. More specifically, Intel
SGX is a set of CPU exten-sions capable of providing
hardware-protected enclave for generic computations. It enables a
host to instantiate multiple enclaves at the same time. An enclave
is isolated from other enclaves, from the operating system (OS),
and from the host itself. Each enclave is associated with a
protected address space. The trusted processor blocks any
non-enclave code’s attempt to access the enclave memory. Memory
pages can be swapped out of the enclave memory, but it is encrypted
using the processor’s key prior to leaving the enclave. Moreover,
Intel SGX provides attestation mechanisms that allows an attesting
enclave to demonstrate to a validator that it has been properly
instantiated with the correct code. In addition, the attestation
mechanism also enables the attesting enclave and the validator to
establish a secure, authenticated channel via which they can
securely communicate sensitive data.
To enable fair exchange between the clients and compute nodes,
we intend to design a novel hybrid architecture that combines
enclave-based metering with blockchain micropayment channel. More
specifically, the OVF Platform intends to incorporate in each
enclave that houses the outsourced computation an accounting logic
that correctly meters the compute node’s work. Such metering is
then translated to a payment promise with which the compute node
can settle the escrow and claim the corresponding reward. This
should allow the fair exchange between the client’s payment and the
compute node’s work in executing the out-sourced task, without
incurring high overhead (i.e., transaction fee) or involving a
trusted third party
Figure 4: Transactions in our Decentralized Computation
Marketplace
We intend to overcome the limitations of existing blockchain
platforms by taking a princi-pled approach that adapts sharding to
Byzantine failure model of blockchain systems, and in doing so,
improve their transaction throughputs at scale. Put differently, as
the number of participants in the OVF Platform grows, so does its
throughput capacity. At a high level, sharding technique still
divides the blockchain network into smaller committees uniformly at
random. To ensure the security of the committee formation, an
unbiased distributed randomness generating protocol needs to be
designed, leveraging recent enclave execution primitives of modern
CPUs (e.g., Intel Skylake proces-sors) to improve the protocol’s
latency. Unlike traditional sharding in the database, it is
intended that each committee in the OVF blockchain system runs an
optimized Byzantine fault-tolerant (BFT) consensus protocol to
ensure their safety, instead of a crash failure tolerant
replication protocol.
Another difference with the traditional database is that the
coordination of cross-shard transactions (i.e., transaction that
affects the state of multiple committees at once) in our envisaged
sharded blockchain is Byzantine-fault tolerant and non-blocking,
which are essen-tial to guarantee consistency of the complex and
distributed transactions.
It is also worth mentioning that we intend the OVF Platform to
support autonomous smart contract with general workloads and
applications that go beyond crypto-currency. Via these smart
contracts, we can anchor various services and marketplaces on top
of the OVF Plat-form, offering them both security and performance
at the same time. The prototype attains a transaction throughput
rivalling that of Visa while enjoying decentralization and high
level of Byzantine fault-tolerance and security. Given our CTO’s
capability of delivering technological advancement, especially the
envis-aged high transactional speed of the OVF Platform, we expect
to be in a unique position to work with other technology companies
s to integrate OVF Platform’s core technical compe-tencies into
their systems, and in doing so, allow them to scale.
We will evaluate and select technology start-ups to incubate
using OVF Tokens and on-board such start-ups onto OVF Platform. In
return, we intend to, in compliance with all applicable laws and
within the concept of OVF Tokens being an utility token, to enter
into arrangements with such start-ups that we incubate to commit an
agreed percentage of their revenue or profit to purchase OVF
Tokens. This will create a demand, circulation and liquidity for
OVF Tokens with the ecosystem.
III. THE NATIVE TOKEN Besides security and performance, one key
component of any service and/or marketplace is a “currency” (or a
token system) that is used to facilitate payments. Such a currency
should be implemented on the blockchain (i.e., native to the
blockchain), to ease the logic and work-flow of the smart contracts
implemented for the services/marketplaces. We therefore intend to
build a token based on our envisaged OVF blockchain (“OVF
Token”).
Fortunately, after the OVF blockchain is created, a token system
is surprisingly easy to imple-
ment on the anticipated OVF blockchain, as it is going to be
fundamentally a database with one operation: subtract X units from
one debit account and gives X units to a credit account, provided
of course that the debit account has sufficient balance to
accommodate the opera-tion, and it is authenticated by the debit
account’s owner
The core issue of blockchain technology not being able to be
scaled due to the lack in trans-actional speed is expected to be
overcome by our intended core scaling technology. This would allow
the OVF Platform to be integrated into the various commonly owned
technolog-ical start-ups’ ecosystems. In the following, we discuss
two particular practical examples where the logic and/or the
operations of the broker/service provider can be implemented in
smart contracts on the OVF Platform, thereby offering both security
(i.e., no single point of failure) and high transaction
throughput.
IV. A DECENTRALISED MARKETPLACE FOR OUTSOURCED COMPUTATION
The cloud computing paradigm offers its clients convenient and
on-demand access to a shared pool of computing resources, enabling
the latter to provide scalable services with minimal management
effort. Nonetheless, it is worth noting that all such conveniences
are offered by and at the discretion of a few specific service
providers. This has raised various security con-cerns. We aim to
disrupt this status quo by introducing a fair marketplace for
secure outsourced computations. In particular, our envisaged novel
cloud computing paradigm aggre-gates computational resources
provisioned by a large cohort of independent compute nodes, and
offer them to end-users. Moreover, our envisaged framework is
intended to be capable of protecting the confidentiality of
clients’ inputs and the integrity of the outsourced computa-tion,
as well as mediating exchanges between the clients’ payments and
the compute nodes’ work in servicing the clients’ requests without
relying on a trusted third party.
Figure 3: Decentralized Marketplace for Outsourced
Computation
SHARD
100NODES
100NODES
100NODES
100NODES
100NODES
100NODES
100NODES
100NODES
100NODES
SHARD SHARD SHARD SHARD SHARD SHARD SHARD SHARD
EVERY TRANSACTION IS PROCESSEDBY EVERY NODE
1000 NODES
-
V. SMART-CONTRACT POWERED TOURISM-INSURANCE Tourism-insurance
have always been a lucrative industry sector. An insurance contract
is typi-cally held between the insurer and the policyholder,
wherein the latter makes an initial pay-ment, or premium, to the
former in exchange for a promise that the insurer will cover the
loss that the insured suffer in case of travel inconvenience or
unexpected incidents. The essence of such an insurance contract can
be deemed as a set of “if then ”. Nonetheless, these conditions are
often intentionally defined vaguely by the insurer in order to
maximize their profit. At the same time, policyholders may attempt
to perform fake claims, lie, and cheat to get the payout. That is,
an ill-managed insurance system will leave both sides unhappy with
each other or even lead to court litigation. There remains a
significant avenue for improvement in the tourism-insurance
industry, and smart contracts, armed with its special properties,
including transparency, autonomy and accuracy, are poised to do
just that. By leveraging smart contracts, both insurer and
policy-holder are able to manage premium and settle claims in a
transparent and accountable manner. In particular, the contract
policy can be recorded and verified on the blockchain’s
tamper-proof ledger. Upon a claim being submitted, the blockchain
ensures that only valid claims are indemnified, and
settlement/payment of the claim is conducted in a fair and
autonomous fashion. In particular, a policyholder cannot submit
multiple claims for the same incident, and the insurer cannot pay a
compensation that is lower than what the policyholder is rightfully
entitled to.
While constructing an insurance system leveraging blockchain and
smart contracts appears rather intuitive, avid readers should have
realised a subtlety that is easily overlooked, which is, in order
for the system to operate, the smart contract requires trustworthy
data feeds (aka oracles) for access to data about real-world state
and events. Unfortunately, an ecosys-tem of trustworthy data feeds
is yet to be realised, which is a critical obstacle to the wide
adoption of smart contracts as financial instruments. We envision
to sidestep this problem by building an authenticated data feed for
smart con-tracts system, taking advantage of Intel SGX’s trusted
execution environment to ensure security. In a nutshell, the
authenticated data feed essentially acts as a bridged between
HTTPS-enabled data websites and the smart contract of the
blockchain. More specifically, the SGX-empowered authenticated data
feed pulls data about real-world state and events from recognised
and trustworthy HTTPS-enabled data websites, and relay them to the
smart contract in such a way that the integrity and authenticity of
the data source are preserved. This is achieved by executing the
core functionality of the authenticated data feed as a trust-ed
piece of code inside an SGX enclave, thereby protecting against
malicious adversaries that wish to tamper with its execution.
Figure 5: smartcontract-empowered insurance
I. TOWARD DECENTRALIZED MARKETPLACES
Our vision is to bring transparency, security, and convenience
to a broad host of transaction-al services and financial services
using blockchain technology.
A great many of today’s digital marketplaces, for instances
insurance-tourism and cloud com-puting, can be facilitated and
benefit from blockchain technology, if only such blockchain
technology can be scaled!
Based on OVF CTO’s ground-breaking research, OVF intends to
build a performative, high-throughput blockchain platform that
supports general-purpose workloads, and then codify the service’s
logic into autonomous smart contracts running on the OVF blockchain
which will enshrine the blockchain advantage of security and
transparency but with a very high transaction throughput (“OVF
Platform”).
Figure 1: Smart Contract vis-a-vis traditional contract
II. SCALING BLOCKCHAINS
Designing a performative and general-purpose blockchain system
has proven to be a challenging feat, as demonstrated by the
limitations of existing blockchain platform. For example: -
Ethereum suffers from low throughput, - EOS lacks decentralization,
- Zilliqa faces difficulties in handling generic transactions, and
the list goes on.
Resolving these challenges are daunting for various reasons.
Firstly, the adversary has excel-lent economic incentives to
deviate from its expected behaviours with respect to the
block-chain protocol, due to the very nature of financial services
built on top of the blockchain. Sec-ondly, that miners, which are
nodes that participates in maintaining and securing the block-chain
states, are typically distributed across the world, complicates and
affects transaction speed as the communication between nodesmay not
be synchronous. Thirdly, the sheer number of participants, the lack
of an inherent Public-Key Infrastructure, the very nature of
decentralization altogether, and Sybil attack.
Interestingly, one can solve a puzzle of the present by looking
far enough into the past. In this spirit, we systematically revisit
the data management and distributed computing litera-ture and make
a critical observation that blockchain is ultimately a distributed
ledger that commands security in the face of the Byzantine
adversary. This observation is essentially a bridge that connects
the blockchain puzzle to several decades of extensive and
well-studied research in the domain of distributed data management.
In that realm, sharding is a promi-nent and proven technique to
scale-out databases.
In a nutshell, sharding divides the database into smaller
components, called “shards”, and let each shard be managed by a
somewhat independent subset of nodes.
By distributing workloads among the shards and simultaneously
executing them in a coordi-nated manner, we can scale the
transaction throughput alongside with the network size, thereby
improving transaction throughput. However, extending sharding to
blockchain systems is no simple feat, due to the fundamental
difference in failure models between databases and blockchain. The
former assumes crash-failures, whereas the latter guards against
Byzantine failures.
Figure 2: Sharding the Blockchain
Our paradigm leverages on Intel SGX’s enclave execution to
enable confidentiality and integ-rity protection of clients’ inputs
and outsourced computation. Abstractly, the trusted execu-tion
environment (TEE) provisioned by SGX, called an enclave, prevents
other applications, the operating system and even the host owner of
the compute node from tampering with the execution of application
loaded within or observing its state, thus guaranteeing data
confidentiality and computation integrity. More specifically, Intel
SGX is a set of CPU exten-sions capable of providing
hardware-protected enclave for generic computations. It enables a
host to instantiate multiple enclaves at the same time. An enclave
is isolated from other enclaves, from the operating system (OS),
and from the host itself. Each enclave is associated with a
protected address space. The trusted processor blocks any
non-enclave code’s attempt to access the enclave memory. Memory
pages can be swapped out of the enclave memory, but it is encrypted
using the processor’s key prior to leaving the enclave. Moreover,
Intel SGX provides attestation mechanisms that allows an attesting
enclave to demonstrate to a validator that it has been properly
instantiated with the correct code. In addition, the attestation
mechanism also enables the attesting enclave and the validator to
establish a secure, authenticated channel via which they can
securely communicate sensitive data.
To enable fair exchange between the clients and compute nodes,
we intend to design a novel hybrid architecture that combines
enclave-based metering with blockchain micropayment channel. More
specifically, the OVF Platform intends to incorporate in each
enclave that houses the outsourced computation an accounting logic
that correctly meters the compute node’s work. Such metering is
then translated to a payment promise with which the compute node
can settle the escrow and claim the corresponding reward. This
should allow the fair exchange between the client’s payment and the
compute node’s work in executing the out-sourced task, without
incurring high overhead (i.e., transaction fee) or involving a
trusted third party
Figure 4: Transactions in our Decentralized Computation
Marketplace
OVF & ECOSYSTEM
09
We intend to overcome the limitations of existing blockchain
platforms by taking a princi-pled approach that adapts sharding to
Byzantine failure model of blockchain systems, and in doing so,
improve their transaction throughputs at scale. Put differently, as
the number of participants in the OVF Platform grows, so does its
throughput capacity. At a high level, sharding technique still
divides the blockchain network into smaller committees uniformly at
random. To ensure the security of the committee formation, an
unbiased distributed randomness generating protocol needs to be
designed, leveraging recent enclave execution primitives of modern
CPUs (e.g., Intel Skylake proces-sors) to improve the protocol’s
latency. Unlike traditional sharding in the database, it is
intended that each committee in the OVF blockchain system runs an
optimized Byzantine fault-tolerant (BFT) consensus protocol to
ensure their safety, instead of a crash failure tolerant
replication protocol.
Another difference with the traditional database is that the
coordination of cross-shard transactions (i.e., transaction that
affects the state of multiple committees at once) in our envisaged
sharded blockchain is Byzantine-fault tolerant and non-blocking,
which are essen-tial to guarantee consistency of the complex and
distributed transactions.
It is also worth mentioning that we intend the OVF Platform to
support autonomous smart contract with general workloads and
applications that go beyond crypto-currency. Via these smart
contracts, we can anchor various services and marketplaces on top
of the OVF Plat-form, offering them both security and performance
at the same time. The prototype attains a transaction throughput
rivalling that of Visa while enjoying decentralization and high
level of Byzantine fault-tolerance and security. Given our CTO’s
capability of delivering technological advancement, especially the
envis-aged high transactional speed of the OVF Platform, we expect
to be in a unique position to work with other technology companies
s to integrate OVF Platform’s core technical compe-tencies into
their systems, and in doing so, allow them to scale.
We will evaluate and select technology start-ups to incubate
using OVF Tokens and on-board such start-ups onto OVF Platform. In
return, we intend to, in compliance with all applicable laws and
within the concept of OVF Tokens being an utility token, to enter
into arrangements with such start-ups that we incubate to commit an
agreed percentage of their revenue or profit to purchase OVF
Tokens. This will create a demand, circulation and liquidity for
OVF Tokens with the ecosystem.
III. THE NATIVE TOKEN Besides security and performance, one key
component of any service and/or marketplace is a “currency” (or a
token system) that is used to facilitate payments. Such a currency
should be implemented on the blockchain (i.e., native to the
blockchain), to ease the logic and work-flow of the smart contracts
implemented for the services/marketplaces. We therefore intend to
build a token based on our envisaged OVF blockchain (“OVF
Token”).
Fortunately, after the OVF blockchain is created, a token system
is surprisingly easy to imple-
ment on the anticipated OVF blockchain, as it is going to be
fundamentally a database with one operation: subtract X units from
one debit account and gives X units to a credit account, provided
of course that the debit account has sufficient balance to
accommodate the opera-tion, and it is authenticated by the debit
account’s owner
The core issue of blockchain technology not being able to be
scaled due to the lack in trans-actional speed is expected to be
overcome by our intended core scaling technology. This would allow
the OVF Platform to be integrated into the various commonly owned
technolog-ical start-ups’ ecosystems. In the following, we discuss
two particular practical examples where the logic and/or the
operations of the broker/service provider can be implemented in
smart contracts on the OVF Platform, thereby offering both security
(i.e., no single point of failure) and high transaction
throughput.
IV. A DECENTRALISED MARKETPLACE FOR OUTSOURCED COMPUTATION
The cloud computing paradigm offers its clients convenient and
on-demand access to a shared pool of computing resources, enabling
the latter to provide scalable services with minimal management
effort. Nonetheless, it is worth noting that all such conveniences
are offered by and at the discretion of a few specific service
providers. This has raised various security con-cerns. We aim to
disrupt this status quo by introducing a fair marketplace for
secure outsourced computations. In particular, our envisaged novel
cloud computing paradigm aggre-gates computational resources
provisioned by a large cohort of independent compute nodes, and
offer them to end-users. Moreover, our envisaged framework is
intended to be capable of protecting the confidentiality of
clients’ inputs and the integrity of the outsourced computa-tion,
as well as mediating exchanges between the clients’ payments and
the compute nodes’ work in servicing the clients’ requests without
relying on a trusted third party.
Figure 3: Decentralized Marketplace for Outsourced
Computation
-
V. SMART-CONTRACT POWERED TOURISM-INSURANCE Tourism-insurance
have always been a lucrative industry sector. An insurance contract
is typi-cally held between the insurer and the policyholder,
wherein the latter makes an initial pay-ment, or premium, to the
former in exchange for a promise that the insurer will cover the
loss that the insured suffer in case of travel inconvenience or
unexpected incidents. The essence of such an insurance contract can
be deemed as a set of “if then ”. Nonetheless, these conditions are
often intentionally defined vaguely by the insurer in order to
maximize their profit. At the same time, policyholders may attempt
to perform fake claims, lie, and cheat to get the payout. That is,
an ill-managed insurance system will leave both sides unhappy with
each other or even lead to court litigation. There remains a
significant avenue for improvement in the tourism-insurance
industry, and smart contracts, armed with its special properties,
including transparency, autonomy and accuracy, are poised to do
just that. By leveraging smart contracts, both insurer and
policy-holder are able to manage premium and settle claims in a
transparent and accountable manner. In particular, the contract
policy can be recorded and verified on the blockchain’s
tamper-proof ledger. Upon a claim being submitted, the blockchain
ensures that only valid claims are indemnified, and
settlement/payment of the claim is conducted in a fair and
autonomous fashion. In particular, a policyholder cannot submit
multiple claims for the same incident, and the insurer cannot pay a
compensation that is lower than what the policyholder is rightfully
entitled to.
While constructing an insurance system leveraging blockchain and
smart contracts appears rather intuitive, avid readers should have
realised a subtlety that is easily overlooked, which is, in order
for the system to operate, the smart contract requires trustworthy
data feeds (aka oracles) for access to data about real-world state
and events. Unfortunately, an ecosys-tem of trustworthy data feeds
is yet to be realised, which is a critical obstacle to the wide
adoption of smart contracts as financial instruments. We envision
to sidestep this problem by building an authenticated data feed for
smart con-tracts system, taking advantage of Intel SGX’s trusted
execution environment to ensure security. In a nutshell, the
authenticated data feed essentially acts as a bridged between
HTTPS-enabled data websites and the smart contract of the
blockchain. More specifically, the SGX-empowered authenticated data
feed pulls data about real-world state and events from recognised
and trustworthy HTTPS-enabled data websites, and relay them to the
smart contract in such a way that the integrity and authenticity of
the data source are preserved. This is achieved by executing the
core functionality of the authenticated data feed as a trust-ed
piece of code inside an SGX enclave, thereby protecting against
malicious adversaries that wish to tamper with its execution.
Figure 5: smartcontract-empowered insurance
I. TOWARD DECENTRALIZED MARKETPLACES
Our vision is to bring transparency, security, and convenience
to a broad host of transaction-al services and financial services
using blockchain technology.
A great many of today’s digital marketplaces, for instances
insurance-tourism and cloud com-puting, can be facilitated and
benefit from blockchain technology, if only such blockchain
technology can be scaled!
Based on OVF CTO’s ground-breaking research, OVF intends to
build a performative, high-throughput blockchain platform that
supports general-purpose workloads, and then codify the service’s
logic into autonomous smart contracts running on the OVF blockchain
which will enshrine the blockchain advantage of security and
transparency but with a very high transaction throughput (“OVF
Platform”).
Figure 1: Smart Contract vis-a-vis traditional contract
II. SCALING BLOCKCHAINS
Designing a performative and general-purpose blockchain system
has proven to be a challenging feat, as demonstrated by the
limitations of existing blockchain platform. For example: -
Ethereum suffers from low throughput, - EOS lacks decentralization,
- Zilliqa faces difficulties in handling generic transactions, and
the list goes on.
Resolving these challenges are daunting for various reasons.
Firstly, the adversary has excel-lent economic incentives to
deviate from its expected behaviours with respect to the
block-chain protocol, due to the very nature of financial services
built on top of the blockchain. Sec-ondly, that miners, which are
nodes that participates in maintaining and securing the block-chain
states, are typically distributed across the world, complicates and
affects transaction speed as the communication between nodesmay not
be synchronous. Thirdly, the sheer number of participants, the lack
of an inherent Public-Key Infrastructure, the very nature of
decentralization altogether, and Sybil attack.
Interestingly, one can solve a puzzle of the present by looking
far enough into the past. In this spirit, we systematically revisit
the data management and distributed computing litera-ture and make
a critical observation that blockchain is ultimately a distributed
ledger that commands security in the face of the Byzantine
adversary. This observation is essentially a bridge that connects
the blockchain puzzle to several decades of extensive and
well-studied research in the domain of distributed data management.
In that realm, sharding is a promi-nent and proven technique to
scale-out databases.
In a nutshell, sharding divides the database into smaller
components, called “shards”, and let each shard be managed by a
somewhat independent subset of nodes.
By distributing workloads among the shards and simultaneously
executing them in a coordi-nated manner, we can scale the
transaction throughput alongside with the network size, thereby
improving transaction throughput. However, extending sharding to
blockchain systems is no simple feat, due to the fundamental
difference in failure models between databases and blockchain. The
former assumes crash-failures, whereas the latter guards against
Byzantine failures.
Figure 2: Sharding the Blockchain
Our paradigm leverages on Intel SGX’s enclave execution to
enable confidentiality and integ-rity protection of clients’ inputs
and outsourced computation. Abstractly, the trusted execu-tion
environment (TEE) provisioned by SGX, called an enclave, prevents
other applications, the operating system and even the host owner of
the compute node from tampering with the execution of application
loaded within or observing its state, thus guaranteeing data
confidentiality and computation integrity. More specifically, Intel
SGX is a set of CPU exten-sions capable of providing
hardware-protected enclave for generic computations. It enables a
host to instantiate multiple enclaves at the same time. An enclave
is isolated from other enclaves, from the operating system (OS),
and from the host itself. Each enclave is associated with a
protected address space. The trusted processor blocks any
non-enclave code’s attempt to access the enclave memory. Memory
pages can be swapped out of the enclave memory, but it is encrypted
using the processor’s key prior to leaving the enclave. Moreover,
Intel SGX provides attestation mechanisms that allows an attesting
enclave to demonstrate to a validator that it has been properly
instantiated with the correct code. In addition, the attestation
mechanism also enables the attesting enclave and the validator to
establish a secure, authenticated channel via which they can
securely communicate sensitive data.
To enable fair exchange between the clients and compute nodes,
we intend to design a novel hybrid architecture that combines
enclave-based metering with blockchain micropayment channel. More
specifically, the OVF Platform intends to incorporate in each
enclave that houses the outsourced computation an accounting logic
that correctly meters the compute node’s work. Such metering is
then translated to a payment promise with which the compute node
can settle the escrow and claim the corresponding reward. This
should allow the fair exchange between the client’s payment and the
compute node’s work in executing the out-sourced task, without
incurring high overhead (i.e., transaction fee) or involving a
trusted third party
Figure 4: Transactions in our Decentralized Computation
Marketplace
We intend to overcome the limitations of existing blockchain
platforms by taking a princi-pled approach that adapts sharding to
Byzantine failure model of blockchain systems, and in doing so,
improve their transaction throughputs at scale. Put differently, as
the number of participants in the OVF Platform grows, so does its
throughput capacity. At a high level, sharding technique still
divides the blockchain network into smaller committees uniformly at
random. To ensure the security of the committee formation, an
unbiased distributed randomness generating protocol needs to be
designed, leveraging recent enclave execution primitives of modern
CPUs (e.g., Intel Skylake proces-sors) to improve the protocol’s
latency. Unlike traditional sharding in the database, it is
intended that each committee in the OVF blockchain system runs an
optimized Byzantine fault-tolerant (BFT) consensus protocol to
ensure their safety, instead of a crash failure tolerant
replication protocol.
Another difference with the traditional database is that the
coordination of cross-shard transactions (i.e., transaction that
affects the state of multiple committees at once) in our envisaged
sharded blockchain is Byzantine-fault tolerant and non-blocking,
which are essen-tial to guarantee consistency of the complex and
distributed transactions.
It is also worth mentioning that we intend the OVF Platform to
support autonomous smart contract with general workloads and
applications that go beyond crypto-currency. Via these smart
contracts, we can anchor various services and marketplaces on top
of the OVF Plat-form, offering them both security and performance
at the same time. The prototype attains a transaction throughput
rivalling that of Visa while enjoying decentralization and high
level of Byzantine fault-tolerance and security. Given our CTO’s
capability of delivering technological advancement, especially the
envis-aged high transactional speed of the OVF Platform, we expect
to be in a unique position to work with other technology companies
s to integrate OVF Platform’s core technical compe-tencies into
their systems, and in doing so, allow them to scale.
We will evaluate and select technology start-ups to incubate
using OVF Tokens and on-board such start-ups onto OVF Platform. In
return, we intend to, in compliance with all applicable laws and
within the concept of OVF Tokens being an utility token, to enter
into arrangements with such start-ups that we incubate to commit an
agreed percentage of their revenue or profit to purchase OVF
Tokens. This will create a demand, circulation and liquidity for
OVF Tokens with the ecosystem.
III. THE NATIVE TOKEN Besides security and performance, one key
component of any service and/or marketplace is a “currency” (or a
token system) that is used to facilitate payments. Such a currency
should be implemented on the blockchain (i.e., native to the
blockchain), to ease the logic and work-flow of the smart contracts
implemented for the services/marketplaces. We therefore intend to
build a token based on our envisaged OVF blockchain (“OVF
Token”).
Fortunately, after the OVF blockchain is created, a token system
is surprisingly easy to imple-
OVF & ECOSYSTEM
10
ment on the anticipated OVF blockchain, as it is going to be
fundamentally a database with one operation: subtract X units from
one debit account and gives X units to a credit account, provided
of course that the debit account has sufficient balance to
accommodate the opera-tion, and it is authenticated by the debit
account’s owner
The core issue of blockchain technology not being able to be
scaled due to the lack in trans-actional speed is expected to be
overcome by our intended core scaling technology. This would allow
the OVF Platform to be integrated into the various commonly owned
technolog-ical start-ups’ ecosystems. In the following, we discuss
two particular practical examples where the logic and/or the
operations of the broker/service provider can be implemented in
smart contracts on the OVF Platform, thereby offering both security
(i.e., no single point of failure) and high transaction
throughput.
IV. A DECENTRALISED MARKETPLACE FOR OUTSOURCED COMPUTATION
The cloud computing paradigm offers its clients convenient and
on-demand access to a shared pool of computing resources, enabling
the latter to provide scalable services with minimal management
effort. Nonetheless, it is worth noting that all such conveniences
are offered by and at the discretion of a few specific service
providers. This has raised various security con-cerns. We aim to
disrupt this status quo by introducing a fair marketplace for
secure outsourced computations. In particular, our envisaged novel
cloud computing paradigm aggre-gates computational resources
provisioned by a large cohort of independent compute nodes, and
offer them to end-users. Moreover, our envisaged framework is
intended to be capable of protecting the confidentiality of
clients’ inputs and the integrity of the outsourced computa-tion,
as well as mediating exchanges between the clients’ payments and
the compute nodes’ work in servicing the clients’ requests without
relying on a trusted third party.
Figure 3: Decentralized Marketplace for Outsourced
Computation
-
V. SMART-CONTRACT POWERED TOURISM-INSURANCE Tourism-insurance
have always been a lucrative industry sector. An insurance contract
is typi-cally held between the insurer and the policyholder,
wherein the latter makes an initial pay-ment, or premium, to the
former in exchange for a promise that the insurer will cover the
loss that the insured suffer in case of travel inconvenience or
unexpected incidents. The essence of such an insurance contract can
be deemed as a set of “if then ”. Nonetheless, these conditions are
often intentionally defined vaguely by the insurer in order to
maximize their profit. At the same time, policyholders may attempt
to perform fake claims, lie, and cheat to get the payout. That is,
an ill-managed insurance system will leave both sides unhappy with
each other or even lead to court litigation. There remains a
significant avenue for improvement in the tourism-insurance
industry, and smart contracts, armed with its special properties,
including transparency, autonomy and accuracy, are poised to do
just that. By leveraging smart contracts, both insurer and
policy-holder are able to manage premium and settle claims in a
transparent and accountable manner. In particular, the contract
policy can be recorded and verified on the blockchain’s
tamper-proof ledger. Upon a claim being submitted, the blockchain
ensures that only valid claims are indemnified, and
settlement/payment of the claim is conducted in a fair and
autonomous fashion. In particular, a policyholder cannot submit
multiple claims for the same incident, and the insurer cannot pay a
compensation that is lower than what the policyholder is rightfully
entitled to.
While constructing an insurance system leveraging blockchain and
smart contracts appears rather intuitive, avid readers should have
realised a subtlety that is easily overlooked, which is, in order
for the system to operate, the smart contract requires trustworthy
data feeds (aka oracles) for access to data about real-world state
and events. Unfortunately, an ecosys-tem of trustworthy data feeds
is yet to be realised, which is a critical obstacle to the wide
adoption of smart contracts as financial instruments. We envision
to sidestep this problem by building an authenticated data feed for
smart con-tracts system, taking advantage of Intel SGX’s trusted
execution environment to ensure security. In a nutshell, the
authenticated data feed essentially acts as a bridged between
HTTPS-enabled data websites and the smart contract of the
blockchain. More specifically, the SGX-empowered authenticated data
feed pulls data about real-world state and events from recognised
and trustworthy HTTPS-enabled data websites, and relay them to the
smart contract in such a way that the integrity and authenticity of
the data source are preserved. This is achieved by executing the
core functionality of the authenticated data feed as a trust-ed
piece of code inside an SGX enclave, thereby protecting against
malicious adversaries that wish to tamper with its execution.
Figure 5: smartcontract-empowered insurance
I. TOWARD DECENTRALIZED MARKETPLACES
Our vision is to bring transparency, security, and convenience
to a broad host of transaction-al services and financial services
using blockchain technology.
A great many of today’s digital marketplaces, for instances
insurance-tourism and cloud com-puting, can be facilitated and
benefit from blockchain technology, if only such blockchain
technology can be scaled!
Based on OVF CTO’s ground-breaking research, OVF intends to
build a performative, high-throughput blockchain platform that
supports general-purpose workloads, and then codify the service’s
logic into autonomous smart contracts running on the OVF blockchain
which will enshrine the blockchain advantage of security and
transparency but with a very high transaction throughput (“OVF
Platform”).
Figure 1: Smart Contract vis-a-vis traditional contract
II. SCALING BLOCKCHAINS
Designing a performative and general-purpose blockchain system
has proven to be a challenging feat, as demonstrated by the
limitations of existing blockchain platform. For example: -
Ethereum suffers from low throughput, - EOS lacks decentralization,
- Zilliqa faces difficulties in handling generic transactions, and
the list goes on.
Resolving these challenges are daunting for various reasons.
Firstly, the adversary has excel-lent economic incentives to
deviate from its expected behaviours with respect to the
block-chain protocol, due to the very nature of financial services
built on top of the blockchain. Sec-ondly, that miners, which are
nodes that participates in maintaining and securing the block-chain
states, are typically distributed across the world, complicates and
affects transaction speed as the communication between nodesmay not
be synchronous. Thirdly, the sheer number of participants, the lack
of an inherent Public-Key Infrastructure, the very nature of
decentralization altogether, and Sybil attack.
Interestingly, one can solve a puzzle of the present by looking
far enough into the past. In this spirit, we systematically revisit
the data management and distributed computing litera-ture and make
a critical observation that blockchain is ultimately a distributed
ledger that commands security in the face of the Byzantine
adversary. This observation is essentially a bridge that connects
the blockchain puzzle to several decades of extensive and
well-studied research in the domain of distributed data management.
In that realm, sharding is a promi-nent and proven technique to
scale-out databases.
In a nutshell, sharding divides the database into smaller
components, called “shards”, and let each shard be managed by a
somewhat independent subset of nodes.
By distributing workloads among the shards and simultaneously
executing them in a coordi-nated manner, we can scale the
transaction throughput alongside with the network size, thereby
improving transaction throughput. However, extending sharding to
blockchain systems is no simple feat, due to the fundamental
difference in failure models between databases and blockchain. The
former assumes crash-failures, whereas the latter guards against
Byzantine failures.
Figure 2: Sharding the Blockchain
OVF & ECOSYSTEM
11
Our paradigm leverages on Intel SGX’s enclave execution to
enable confidentiality and integ-rity protection of clients’ inputs
and outsourced computation. Abstractly, the trusted execu-tion
environment (TEE) provisioned by SGX, called an enclave, prevents
other applications, the operating system and even the host owner of
the compute node from tampering with the execution of application
loaded within or observing its state, thus guaranteeing data
confidentiality and computation integrity. More specifically, Intel
SGX is a set of CPU exten-sions capable of providing
hardware-protected enclave for generic computations. It enables a
host to instantiate multiple enclaves at the same time. An enclave
is isolated from other enclaves, from the operating system (OS),
and from the host itself. Each enclave is associated with a
protected address space. The trusted processor blocks any
non-enclave code’s attempt to access the enclave memory. Memory
pages can be swapped out of the enclave memory, but it is encrypted
using the processor’s key prior to leaving the enclave. Moreover,
Intel SGX provides attestation mechanisms that allows an attesting
enclave to demonstrate to a validator that it has been properly
instantiated with the correct code. In addition, the attestation
mechanism also enables the attesting enclave and the validator to
establish a secure, authenticated channel via which they can
securely communicate sensitive data.
To enable fair exchange between the clients and compute nodes,
we intend to design a novel hybrid architecture that combines
enclave-based metering with blockchain micropayment channel. More
specifically, the OVF Platform intends to incorporate in each
enclave that houses the outsourced computation an accounting logic
that correctly meters the compute node’s work. Such metering is
then translated to a payment promise with which the compute node
can settle the escrow and claim the corresponding reward. This
should allow the fair exchange between the client’s payment and the
compute node’s work in executing the out-sourced task, without
incurring high overhead (i.e., transaction fee) or involving a
trusted third party
Figure 4: Transactions in our Decentralized Computation
Marketplace
We intend to overcome the limitations of existing blockchain
platforms by taking a princi-pled approach that adapts sharding to
Byzantine failure model of blockchain systems, and in doing so,
improve their transaction throughputs at scale. Put differently, as
the number of participants in the OVF Platform grows, so does its
throughput capacity. At a high level, sharding technique still
divides the blockchain network into smaller committees uniformly at
random. To ensure the security of the committee formation, an
unbiased distributed randomness generating protocol needs to be
designed, leveraging recent enclave execution primitives of modern
CPUs (e.g., Intel Skylake proces-sors) to improve the protocol’s
latency. Unlike traditional sharding in the database, it is
intended that each committee in the OVF blockchain system runs an
optimized Byzantine fault-tolerant (BFT) consensus protocol to
ensure their safety, instead of a crash failure tolerant
replication protocol.
Another difference with the traditional database is that the
coordination of cross-shard transactions (i.e., transaction that
affects the state of multiple committees at once) in our envisaged
sharded blockchain is Byzantine-fault tolerant and non-blocking,
which are essen-tial to guarantee consistency of the complex and
distributed transactions.
It is also worth mentioning that we intend the OVF Platform to
support autonomous smart contract with general workloads and
applications that go beyond crypto-currency. Via these smart
contracts, we can anchor various services and marketplaces on top
of the OVF Plat-form, offering them both security and performance
at the same time. The prototype attains a transaction throughput
rivalling that of Visa while enjoying decentralization and high
level of Byzantine fault-tolerance and security. Given our CTO’s
capability of delivering technological advancement, especially the
envis-aged high transactional speed of the OVF Platform, we expect
to be in a unique position to work with other technology companies
s to integrate OVF Platform’s core technical compe-tencies into
their systems, and in doing so, allow them to scale.
We will evaluate and select technology start-ups to incubate
using OVF Tokens and on-board such start-ups onto OVF Platform. In
return, we intend to, in compliance with all applicable laws and
within the concept of OVF Tokens being an utility token, to enter
into arrangements with such start-ups that we incubate to commit an
agreed percentage of their revenue or profit to purchase OVF
Tokens. This will create a demand, circulation and liquidity for
OVF Tokens with the ecosystem.
III. THE NATIVE TOKEN Besides security and performance, one key
component of any service and/or marketplace is a “currency” (or a
token system) that is used to facilitate payments. Such a currency
should be implemented on the blockchain (i.e., native to the
blockchain), to ease the logic and work-flow of the smart contracts
implemented for the services/marketplaces. We therefore intend to
build a token based on our envisaged OVF blockchain (“OVF
Token”).
Fortunately, after the OVF blockchain is created, a token system
is surprisingly easy to imple-
ment on the anticipated OVF blockchain, as it is going to be
fundamentally a database with one operation: subtract X units from
one debit account and gives X units to a credit account, provided
of course that the debit account has sufficient balance to
accommodate the opera-tion, and it is authenticated by the debit
account’s owner
The core issue of blockchain technology not being able to be
scaled due to the lack in trans-actional speed is expected to be
overcome by our intended core scaling technology. This would allow
the OVF Platform to be integrated into the various commonly owned
technolog-ical start-ups’ ecosystems. In the following, we discuss
two particular practical examples where the logic and/or the
operations of the broker/service provider can be implemented in
smart contracts on the OVF Platform, thereby offering both security
(i.e., no single point of failure) and high transaction
throughput.
IV. A DECENTRALISED MARKETPLACE FOR OUTSOURCED COMPUTATION
The cloud computing paradigm offers its clients convenient and
on-demand access to a shared pool of computing resources, enabling
the latter to provide scalable services with minimal management
effort. Nonetheless, it is worth noting that all such conveniences
are offered by and at the discretion of a few specific service
providers. This has raised various security con-cerns. We aim to
disrupt this status quo by introducing a fair marketplace for
secure outsourced computations. In particular, our envisaged novel
cloud computing paradigm aggre-gates computational resources
provisioned by a large cohort of independent compute nodes, and
offer them to end-users. Moreover, our envisaged framework is
intended to be capable of protecting the confidentiality of
clients’ inputs and the integrity of the outsourced computa-tion,
as well as mediating exchanges between the clients’ payments and
the compute nodes’ work in servicing the clients’ requests without
relying on a trusted third party.
Figure 3: Decentralized Marketplace for Outsourced
Computation
CLIENT MARKETPLACERESOURCEPROVIDERS
MACHINE 2
MACHINE 3
MACHINE 5
PAYMENTFOR COMPUTING RESOURCE
IN OVF
COMPUTING RESOURCE
REWARD
PAID IN O
VF
INDIVIDUA
L HARDW
ARE
REWARD PAID IN OVF
INDIVIDUAL HARDWARE
REWARD PAID IN OVFINDIVIDUAL HARDWARE
-
OVF & ECOSYSTEM
12
V. SMART-CONTRACT POWERED TOURISM-INSURANCE Tourism-insurance
have always been a lucrative industry sector. An insurance contract
is typi-cally held between the insurer and the policyholder,
wherein the latter makes an initial pay-ment, or premium, to the
former in exchange for a promise that the insurer will cover the
loss that the insured suffer in case of travel inconvenience or
unexpected incidents. The essence of such an insurance contract can
be deemed as a set of “if then ”. Nonetheless, these conditions are
often intentionally defined vaguely by the insurer in order to
maximize their profit. At the same time, policyholders may attempt
to perform fake claims, lie, and cheat to get the payout. That is,
an ill-managed insurance system will leave both sides unhappy with
each other or even lead to court litigation. There remains a
significant avenue for improvement in the tourism-insurance
industry, and smart contracts, armed with its special properties,
including transparency, autonomy and accuracy, are poised to do
just that. By leveraging smart contracts, both insurer and
policy-holder are able to manage premium and settle claims in a
transparent and accountable manner. In particular, the contract
policy can be recorded and verified on the blockchain’s
tamper-proof ledger. Upon a claim being submitted, the blockchain
ensures that only valid claims are indemnified, and
settlement/payment of the claim is conducted in a fair and
autonomous fashion. In particular, a policyholder cannot submit
multiple claims for the same incident, and the insurer cannot pay a
compensation that is lower than what the policyholder is rightfully
entitled to.
While constructing an insurance system leveraging blockchain and
smart contracts appears rather intuitive, avid readers should have
realised a subtlety that is easily overlooked, which is, in order
for the system to operate, the smart contract requires trustworthy
data feeds (aka oracles) for access to data about real-world state
and events. Unfortunately, an ecosys-tem of trustworthy data feeds
is yet to be realised, which is a critical obstacle to the wide
adoption of smart contracts as financial instruments. We envision
to sidestep this problem by building an authenticated data feed for
smart con-tracts system, taking advantage of Intel SGX’s trusted
execution environment to ensure security. In a nutshell, the
authenticated data feed essentially acts as a bridged between
HTTPS-enabled data websites and the smart contract of the
blockchain. More specifically, the SGX-empowered authenticated data
feed pulls data about real-world state and events from recognised
and trustworthy HTTPS-enabled data websites, and relay them to the
smart contract in such a way that the integrity and authenticity of
the data source are preserved. This is achieved by executing the
core functionality of the authenticated data feed as a trust-ed
piece of code inside an SGX enclave, thereby protecting against
malicious adversaries that wish to tamper with its execution.
Figure 5: smartcontract-empowered insurance
I. TOWARD DECENTRALIZED MARKETPLACES
Our vision is to bring transparency, security, and convenience
to a broad host of transaction-al services and financial services
using blockchain technology.
A great many of today’s digital marketplaces, for instances
insurance-tourism and cloud com-puting, can be facilitated and
benefit from blockchain technology, if only such blockchain
technology can be scaled!
Based on OVF CTO’s ground-breaking research, OVF intends to
build a performative, high-throughput blockchain platform that
supports general-purpose workloads, and then codify the service’s
logic into autonomous smart contracts running on the OVF blockchain
which will enshrine the blockchain advantage of security and
transparency but with a very high transaction throughput (“OVF
Platform”).
Figure 1: Smart Contract vis-a-vis traditional contract
II. SCALING BLOCKCHAINS
Designing a performative and general-purpose blockchain system
has proven to be a challenging feat, as demonstrated by the
limitations of existing blockchain platform. For example: -
Ethereum suffers from low throughput, - EOS lacks decentralization,
- Zilliqa faces difficulties in handling generic transactions, and
the list goes on.
Resolving these challenges are daunting for various reasons.
Firstly, the adversary has excel-lent economic incentives to
deviate from its expected behaviours with respect to the
block-chain protocol, due to the very nature of financial services
built on top of the blockchain. Sec-ondly, that miners, which are
nodes that participates in maintaining and securing the block-chain
states, are typically distributed across the world, complicates and
affects transaction speed as the communication between nodesmay not
be synchronous. Thirdly, the sheer number of participants, the lack
of an inherent Public-Key Infrastructure, the very nature of
decentralization altogether, and Sybil attack.
Interestingly, one can solve a puzzle of the present by looking
far enough into the past. In this spirit, we systematically revisit
the data management and distributed computing litera-ture and make
a critical observation that blockchain is ultimately a distributed
ledger that commands security in the face of the Byzantine
adversary. This observation is essentially a bridge that connects
the blockchain puzzle to several decades of extensive and
well-studied research in the domain of distributed data management.
In that realm, sharding is a promi-nent and proven technique to
scale-out databases.
In a nutshell, sharding divides the database into smaller
components, called “shards”, and let each shard be managed by a
somewhat independent subset of nodes.
By distributing workloads among the shards and simultaneously
executing them in a coordi-nated manner, we can scale the
transaction throughput alongside with the network size, thereby
improving transaction throughput. However, extending sharding to
blockchain systems is no simple feat, due to the fundamental
difference in failure models between databases and blockchain. The
former assumes crash-failures, whereas the latter guards against
Byzantine failures.
Figure 2: Sharding the Blockchain
Our paradigm leverages on Intel SGX’s enclave execution to
enable confidentiality and integ-rity protection of clients’ inputs
and outsourced computation. Abstractly, the trusted execu-tion
environment (TEE) provisioned by SGX, called an enclave, prevents
other applications, the operating system and even the host owner of
the compute node from tampering with the execution of application
loaded within or observing its state, thus guaranteeing data
confidentiality and computation integrity. More specifically, Intel
SGX is a set of CPU exten-sions capable of providing
hardware-protected enclave for generic computations. It enables a
host to instantiate multiple enclaves at the same time. An enclave
is isolated from other enclaves, from the operating system (OS),
and from the host itself. Each enclave is associated with a
protected address space. The trusted processor blocks any
non-enclave code’s attempt to access the enclave memory. Memory
pages can be swapped out of the enclave memory, but it is encrypted
using the processor’s key prior to leaving the enclave. Moreover,
Intel SGX provides attestation mechanisms that allows an attesting
enclave to demonstrate to a validator that it has been properly
instantiated with the correct code. In addition, the attestation
mechanism also enables the attesting enclave and the validator to
establish a secure, authenticated channel via which they can
securely communicate sensitive data.
To enable fair exchange between the clients and compute nodes,
we intend to design a novel hybrid architecture that combines
enclave-based metering with blockchain micropayment channel. More
specifically, the OVF Platform intends to incorporate in each
enclave that houses the outsourced computation an accounting logic
that correctly meters the compute node’s work. Such metering is
then translated to a payment promise with which the compute node
can settle the escrow and claim the corresponding reward. This
should allow the fair exchange between the client’s payment and the
compute node’s work in executing the out-sourced task, without
incurring high overhead (i.e., transaction fee) or involving a
trusted third party
Figure 4: Transactions in our Decentralized Computation
Marketplace
We intend to overcome the limitations of existing blockchain
platforms by taking a princi-pled approach that adapts sharding to
Byzantine failure model of blockchain systems, and in doing so,
improve their transaction throughputs at scale. Put differently, as
the number of participants in the OVF Platform grows, so does its
throughput capacity. At a high level, sharding technique still
divides the blockchain network into smaller committees uniformly at
random. To ensure the security of the committee formation, an
unbiased distributed randomness generating protocol needs to be
designed, leveraging recent enclave execution primitives of modern
CPUs (e.g., Intel Skylake proces-sors) to improve the protocol’s
latency. Unlike traditional sharding in the database, it is
intended that each committee in the OVF blockchain system runs an
optimized Byz
