KR102450412B1 - SLA-Based Sharing Economy Service with Smart Contract for Resource Integrity in the Internet of Things - Google Patents

Abstract

The present invention relates to an enhanced decentralized sharing economy service using the service level agreement (SLA) that documents the service and defines the service standards that providers must meet, including participants, assets, blockchain networks, Based on the basic configuration of the chain database, the concept of SLA (Service Level Agreement) is applied to build the self-governing structure of the sharing economy system, and the SLA specification is defined as a smart contract to define the SLA life after all rules for SLA management It can provide a system that automates the cycle and gives transparency to service provisioning.

Description

SLA-Based Sharing Economy Service with Smart Contract for Resource Integrity in the Internet of Things

The present invention relates to enhanced decentralized sharing economy services using the service level agreement (SLA) that documents the services and defines the service standards that providers must meet.

Due to the popularity of peer-to-peer (P2P) platforms, large-scale private-to-person transactions are becoming increasingly frequent. The sharing economy is a peer-to-peer economic model that provides access to goods and services often facilitated by community-based online platforms. This new Internet-based rental marketplace allows individuals to gain additional benefits by renting out goods and services they do not use to others. Mobike, for example, is a fully stationless bike-sharing system, allowing consumers to ride their bikes away at any time or in a parking area.

Another prime example is Airbnb, where individuals can rent their extra rooms, apartments, or entire homes. The sharing economy has exploded rapidly over the past decade, and the potential market size is expected to grow from $14 billion in 2014 to $335 billion in 2025. Advances in information technology and data analytics capabilities pave the way for rental companies to efficiently match supply and demand. Mutual trust is one of the most basic prerequisites for such interactions to occur in the sharing economy. For example, department organizers need to trust not only potential guests to be courteous, but also trust Airbnb's ability to process reservations and payments.

However, as social ties diminish compared to other common sharing platforms in the sharing economy, providers and consumers generally have less information about each other than in traditional exchanges, and as a result, many sharing economy platforms distribute the cost of coordinating the platform to members. In order to do this, a rating system was introduced. However, in such a rating system, although the trust indicated in the user rating can be significant, individual participants take risks disproportionately.

Recently, decentralized technology represented by blockchain has been introduced as a new paradigm by some researchers. Conceptually, a blockchain is a distributed ledger made up of multiple peers that can execute, track, verify, and record transactions across multiple entities. Every block in the ledger is logically linked to the previous block by storing the hash of the parent. As a result, users of the blockchain can easily detect inconsistencies even if they manipulated a single bit of the ledger. This makes it impossible for any party to manipulate data on the blockchain. The sharing economy system built based on blockchain technology improves the efficiency of shared services and reduces operating costs by not accepting transaction trusts.

Blockchain started as a core technology of Bitcoin, but its use cases have already expanded to various fields such as healthcare, intelligent transportation, and the Internet of Things (IoT). Despite the great efforts of many researchers to apply the blockchain technology theory to the sharing economy, it shows existing flaws in the blockchain-based sharing economy system. Its limitations can be summarized in the following points.

First, most systems focus primarily on online transactions and transaction transparency. Moreover, it provides only simple services such as transferring ownership of property using cryptocurrency (e.g. Bitcoin or Ether). So far, there are few literature works that consider actual connection with blockchain. Most importantly, there is a problem of reduced operational governance control because consumers have less control over the actual service level provided by providers compared to in-house services. In general, businesses that provide rental services are always regulated by federal, state or local authorities. However, unlicensed individuals providing rental services in the sharing economy may not comply with these regulations. For example, bikes provided by Mobiq owners have little chance of being compensated, often resulting in users' losses.

In other words, even in a sharing economy system that applies block chains, it does not reach QoS (Quality of Service) for service consumers when contracting business resources that require guarantees for third-party resources, especially outsourced business processes. For example, most of these tasks focus on payment management, but lack of compensation procedures in case of default arises.

Korean Patent Registration No. 10-2019-0091995

'Blockchain Startup Realizing Sharing Economy Infrastructure, Slock.it', Vertical Platform (published on January 29, 2018)

The present invention has been devised to solve the above problems, and the object of the present invention is to build a self-governing structure of a sharing economy system based on the basic configuration of participants, assets, blockchain networks, and off-chain databases. Apply the concept of (Service Level Agreement) and define the SLA specification as a smart contract to provide a system that automates the SLA lifecycle after all rules for SLA (Service Level Agreement) management and gives transparency to service provisioning. .

In addition, in concluding the SLA (service level agreement), according to the service level agreement that meets the demand level of the contracting party (user), the class of the agreement (VIP-Diamond-Platinum, etc.) is divided to provide the service of sharing things It is another object of the present invention to provide a sharing economy system that can provide a customized degree of (secrecy level, data security, reliability, etc.).

As a means for solving the above problems, in an embodiment of the present invention, a service contract for using shared assets is performed under wired/wireless communication, and asset sharing is executed by accessing a blockchain network in which the service contract information is registered. In the method of providing a sharing economy service,

Step 1 in which the manager module defines and registers participants of the sharing economy service on the blockchain network; A second step in which the shared asset provider module including the laptop registers basic information of the shared asset in the block chain network; Step 3 of creating and defining a smart contract related to the shared asset registered by the provider module; Step 4 in which the validator module verifies the smart contract; Step 5 in which the issuer module issues a token to the consumer module; a sixth step in which the consumer module concludes the smart contract and transfers a token to the provider module; A method of providing a smart contract-based sharing economy service, including a; step 7, wherein the consumer module accesses and uses the shared asset through the use authentication password for the shared asset.

According to an embodiment of the present invention, it is possible to provide an enhanced decentralized sharing economy service using a service level agreement (SLA) that documents the service to be provided by the provider and defines the service standard that the provider must meet.

In particular, based on the basic composition of participants, assets, blockchain networks, and off-chain databases, the concept of SLA (Service Level Agreement) is applied to build a self-governing structure of the sharing economy system, and the SLA specification is converted into a smart contract. By defining it, you can provide a system that automates the SLA lifecycle after all rules for managing SLAs and gives transparency to service provisioning.

Furthermore, it is possible to provide an efficient and automatic approach for service quality assurance and service control automation for the assets provided by the sharing economy system. In particular, in the embodiment of the present invention, in concluding the SLA (service level agreement), according to the service level agreement that meets the level of demand of the contracting party (user), the level of the agreement (VIP-Diamond-Platinum, etc.) By classifying it, it is possible to provide a sharing economy system that can customize the degree of service provision (secrecy maintenance, data security, reliability, etc.) of sharing things.

1 is a block diagram of the implementation of a smart contract-based sharing economy service providing system according to an embodiment of the present invention.
FIG. 2 shows a block diagram of the block chain network in FIG. 1 .
3 is a conceptual diagram illustrating a service level agreement (SLA)-based sharing economy service through a smart contract according to the present invention, and FIG. 4 is a conceptual diagram illustrating the interaction of the sharing economy service according to the present invention. 5 is a block diagram illustrating a relationship between a Service Level Agreement (SLA) specification and a participant and a smart contract according to the present invention. 6 is a conceptual diagram of the blockchain network described above in FIGS. 1 and 2 .
7 and 8 are conceptual diagrams for explaining authentication-related technical means.
9 shows a transaction operation process of a blockchain network according to the present invention.
Fig. 10 details the SLA specification specified in the notebook sharing application in this embodiment.
11 illustrates a logical operation method of a transaction defined in a smart contract.
12 shows the interaction between the blockchain and the off-chain database.
13 shows a simplified workflow of a notebook sharing case study to which an embodiment of the present invention is applied.
14 is an authentication schematic diagram in which the client is protected by the OAuth2.0 scheme.
15 illustrates a sample participant certificate issued by Fabric-CA using X.509.
16 is an image showing the results of the notebook sharing case described above.
Figure 17 shows the Composer REST Server Explorer used to inspect and test the generated REST API.
18 shows an image of the playground wallet API described above.
19 shows a transaction test of Composer REST Server.
20 is an example of a provider profile defined in a smart contract.
21 shows a snapshot of the transaction record of the Composer Playground, including date, input type and participant.
22 to 25 are data images related to performance evaluation of the system according to the present invention.

Advantages and features of the present invention, and methods of achieving them, will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be implemented in various different forms.

In the present specification, the present embodiment is provided to complete the disclosure of the present invention, and to completely inform those of ordinary skill in the art to which the present invention pertains to the scope of the present invention. And the invention is only defined by the scope of the claims. Thus, in some embodiments, well-known components, well-known operations, and well-known techniques have not been specifically described to avoid obscuring the present invention.

1 is a block diagram of an implementation of a smart contract-based sharing economy service providing system (hereinafter referred to as 'the present invention') according to an embodiment of the present invention. FIG. 2 shows a block diagram of the block chain network in FIG. 1 .

1 and 2, the present invention provides a sharing economy system that performs a use service contract for shared assets under wired/wireless communication and executes asset sharing by accessing a blockchain network in which the service contract information is registered. do.

To this end, based on the database 300 for information classified as shared assets or the asset information separately provided by the participant, the participant accesses the blockchain network 200 through a terminal capable of wired/wireless communication and provides a service for asset sharing It will be possible to implement the process of executing contracts and using shared assets.

In the present invention, "~ module" is defined as a concept including a user terminal in which each subject, a participant who uses and operates the system, accesses the block chain network.

The subject constituting the sharing economy system in the present invention, the sharing economy system includes a plurality of participant modules 100, wherein the participant module is a provider module that provides a necessary solution or service asset based on a service level agreement template (110), a validator module 120 that verifies the validity of the smart contract based on the service level contract template registered by the provider on the blockchain network, and the validation of the smart contract to use the shared asset according to the smart contract The consumer module 130 that confirms the result, concludes a contract for using shared assets, monitors compliance with the contract standards included in the smart contract, and inspects whether the guarantee for service use is complied with, and performs compensation in case of violation. It may be configured to include a monitor module 140, and an issuer module 150 that is generated by tokenizing the value of the service asset related to the smart contract.

Specifically, the sharing economy service providing system according to the present invention includes the participants participating through the participant module 100, the assets stored in the shared asset DB 300, the blockchain network 200, and the off-chain database 400. It consists of four elements. Participants and assets are fundamental to the shared business model. Participants are actors with unique roles, for example users or providers of assets who want to automatically discover and rent assets based on certain conditions.

An asset is a good, service, or property that can be controlled by an electronic lock or access control system. An asset can represent almost anything in a business network, for example an empty house or an idle desktop. In the present invention, various sensor data can be collected from sensors attached to assets to monitor the status of these assets.

Participants can perform operations on the blockchain, for example creating new assets or exchanging assets with other participants. All interactions between participants and the blockchain are encrypted with digital signatures to ensure the security of data transmission and the authenticity of the participant's identity.

The blockchain network 200 consists of various trusted peers that hold copies of smart contracts and network ledgers to maintain data consistency within the network.

Smart contracts act as trusted decentralized applications that perform business logic running on the blockchain. The smart contract can perform simple tasks, such as updating data, or complex tasks that require sub-conditions. Blockchain preserves a data history of all transactions along the lifecycle of a particular asset. The off-chain database is an independent data storage that holds the current values of participants and assets, stores information that changes later, and provides it to the blockchain network.

The block chain network 200 includes a smart contract registration unit 210 in which the smart contract approved information concluded between the provider module and the consumer module is registered on the block chain network, and blocks the smart contract related information. Distributed ledger generation unit 220 that implements a distributed ledger to be shared with users on the system, ID authentication unit 230 that authenticates access rights of subjects accessing the distributed ledger, and the validator module for validating the smart contract The verification unit 240 that verifies through The API interface unit 260, which discloses the provided service as an open API system that allows client applications to interact with smart contracts, and a defect correction unit that verifies the validity of information written in the distributed ledger through the Byzantine Fault Tolerance (PBFT) algorithm. 270 may be included. The functional configuration of such a block chain network can be embodied as shown in FIGS. 4 and 6 .

3 is a conceptual diagram illustrating a service level agreement (SLA)-based sharing economy service through a smart contract according to the present invention, and FIG. 4 is a conceptual diagram illustrating the interaction of the sharing economy service according to the present invention. 5 is a block diagram illustrating a relationship between a Service Level Agreement (SLA) specification and a participant and a smart contract according to the present invention. 6 is a conceptual diagram of the blockchain network described above in FIGS. 1 and 2 .

The process of accessing the blockchain network through the participant module will be described with reference to FIGS. 3 and 4 .

3 and 4, each participant submits a client through the participant module 100, and isolates the submitting client from the blockchain network. The submitting client is just used to invoke the smart contract and be notified whenever the blockchain network contains a new transaction on the ledger.

Participants are members of a business network with the ability to own assets and submit transactions.

In addition, assets can invoke smart contracts when sending collected sensing data. This data is used to create various methods for services such as remote troubleshooting and maintenance.

Participant Registry in the blockchain network 200 holds instances of created participants, whereas asset registration holds asset instances. In this work, enrollment certificates are used as identity mappings for participants, and these certificates are maintained in an identity registry. Whenever an administrator restricts an identity to a participant, the blockchain network creates a new mapping to the identity registry.

As a result, the network can verify the identity in the identity registry when a participant submits a transaction. After identification, the participant becomes the current participant who can submit transactions. Access control in smart contracts manages access to resources by associating policies. These rules of the blockchain network apply to current participants performing authorized actions on resources in accordance with access control requirements.

The present invention provides a mechanism for specifying the components of the service level agreement (SLA) based on a smart contract. The most characteristic feature of SLA (the service level agreement, hereinafter referred to as 'SLA') is that it obliges to provide services to consumers as agreed in the contract, and monitoring and penalties for violations thereof and to provide compensation.

In addition, in the present invention, in concluding a service level agreement (SLA), according to the service requirement level that meets the request level of the contracting party (user), the level of the agreement (VIP-Diamond-Platinum, etc.) It is possible to provide a sharing economy system that can provide a customized level of sharing service provision (secrecy level, data security, reliability, etc.).

In addition, financial transactions in the sharing economy service model proposed in the present invention are automated and intelligently managed by the SLA contract, and all participants in the reliable operation that the SLA contract in the present invention studies the contract and obligations are human It runs automatically without any intervention. This system according to the present invention is provided as a shared asset, reports failures on contracted assets, processes payments and refunds, monitors performance indicators, performs data analysis, and enables decisions to be made.

5, the system according to the present invention defines five participants, including a verifier, a provider, a consumer, a publisher, and a supervisor, and each participant accesses the system through a user terminal to participate. do.

First, a provider participating through the provider module 110 is a vendor that provides a necessary solution or service based on the SLA contract template. The verifier verifies the SLA registered in the system and responds to the system with the verification result. In particular, in the case of the present invention, the level of security, object, and shared service can be determined and provided according to the service level agreement requested by the consumer, the integrity of the provider and user is improved, and the data security and reliability of the contract are guaranteed make it possible Accordingly, the level of the agreement is set according to the level of service required that meets the level of the contracting party (user) (for example, VIP-Diamond-Platinum, etc.) retention, data security, reliability, etc.) can be customized.

Next, the consumer, participating through the consumer module 130 , may check the SLA and related validation results.

The monitor participating through the monitor module 140 continuously monitors the service performance according to each guarantee presented in the smart contract. If these warranties are violated, the monitor notifies the system. Penalties are evaluated for performing each reward action associated with them as dictated by the smart contract. The scope of such monitoring is to be performed including whether or not to comply with the level of service requested by the consumer in the contract, compliance with the agreement, security, data security, and the level of shared service.

Moreover, charging is performed automatically according to the cost of the corresponding service. Of course, it is preferable that the service cost is set differentially according to the level according to the service demand level of the consumer at the time of the initial contract so that the charging is executed. The SLA contract automatically terminates when the contract validity period expires. However, the information in the SLA agreement may remain in the system for the time being for liability and legal reasons. After that period, the contract may be terminated as in the case of a regular contract. In the case of reuse, the specification shall be preserved in the system.

In addition, the issuer participating through the issuer module 150 is a legal entity having the authority to issue securities or tokens. Created tokens, so-called IoT coins, are specific coins that providers can tokenize their assets. Representing assets as tokens establishes the individual status and permissions of an item, reducing the risk and difficulty of transferring assets across multiple parties.

Assets applied to the present invention can be applied to two types of assets: intangible assets and tangible assets. Tangible assets are physical assets (eg cars, homes, desktops, laptops) that can be controlled by electronic locks or access control systems. Intangible assets include non-physical properties (eg sensor data, access keys) that can be controlled by a digital device.

However, these two assets share many standard features. For example, they can be sent directly to the network or controlled by a smart device. Moreover, since there are no traditional steps such as storage or logistics, assets can be received immediately upon completion of the transaction.

Participants are associated with the asset, but can realize the transfer of usage rights by token transfer or digital control. In a real environment, the anti-theft system can only be unlocked with the right key equipped with the corresponding private key provided by the anti-theft system.

The private key is usually stored in a physical container (eg a SIM card), making it difficult to transmit. In the blockchain, permission can be made in the network, so in the shared business system according to the present invention, a mobile device equipped with a short-range wireless communication module can be used as a telecommunication company, and the permission to use the blockchain can be transferred using the APP. .

6 is a diagram conceptualizing the configuration of the block chain network described above in FIGS. 1 and 2 .

As shown in Fig. 6, the blockchain network 200 of the present invention is built in a permissioned network that only allows access from authorized users.

This solution avoids the risk of data exposure as transaction records that record how resources are manipulated are not visible to unauthorized users. In a permissioned blockchain network, only permissioned users can operate on the blockchain, and valid blocks must contain the signatures of a subset of users.

As a result, no bad node can modify or insert a transaction in the blockchain. In addition, the approved smart contract cannot be changed unless it is concluded by all user contracts related to operation.

The blockchain network according to the present invention provides various blockchain functions such as ID authentication, verification, and P2P communication. As described above in FIG. 2 , the smart contract registration unit 210 in which the smart contract approved information concluded between the provider module and the consumer module is registered on the block chain network, the smart contract related information is blocked and used on the network A distributed ledger generator 220 that implements a distributed ledger to be shared with subjects, an ID authentication unit 230 that authenticates the access rights of subjects accessing the distributed ledger, and the validity of the smart contract through the verifier module The verification unit 240 that verifies, the event hub unit 250 that generates an event to the client when a new block is added to the distributed ledger or a transaction triggers a condition defined in the smart contract, and the blockchain network provides The API interface unit 260 that discloses the service as an open API system that allows client applications to interact with smart contracts, and the defect correction unit 270 that verifies the validity of information written in the distributed ledger through the Byzantine Fault Tolerance (PBFT) algorithm. ) may be included.

In Fig. 6, each peer maintains the ledger and provides the operating environment of the smart contract, so it can be a participant as a basic entity of the blockchain network.

The orderer peer provides transaction orders that sequentially wrap transactions and create transaction blocks.

The distributed ledger is consensusally shared and synchronized through a blockchain network, where each peer in the network can have an identical copy.

The pragmatic Byzantine Fault Tolerance (PBFT) algorithm provides a mechanism by which peers can accurately reach consensus despite malicious peers sending inaccurate information.

Smart contracts are installed and instantiated by all peers and run as a decentralized application to manage access and modification of the ledger.

The event hub generates an event on the client whenever a new block is added to the ledger, or a transaction triggers a predefined condition in the smart contract.

The API interface exposes the services provided by the blockchain network as an open API system that allows client applications to interact with smart contracts.

This operation utilizes asymmetric encryption, including a key pair to encrypt and decrypt data, as shown in FIG. 7 . A public key is provided by a trusted, designated authority and is often used to encrypt data. The other key in the pair is a private key that is kept secret and is mathematically linked to the public key. In asymmetric cryptography, one of two keys can be used to encrypt a message, but what is encrypted can only be decrypted by its associated opposite key.

A trusted authority, called a public key institution (PKI), allows users and systems to recognize that public keys are genuine and have not been tampered with by malicious third parties.

In particular, as shown in Fig. 8, the PKI architecture of our system consists of a certificate authority (CA) and a certificate database. A Certificate Authority (CA) is a trusted party that provides a source of trust for all PKI certificates and provides services to authenticate, issue, and revoke an individual's identity. Each CA maintains its own root CA, used only by the CA.

CAs certified by the root CA can issue certificates for specific uses permitted by the root. The certificate database stores issued certificates and the validity period and status information of each PKI. Among the various standards of PKI, in the present invention, as an embodiment, the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 5280) ] can be used. X.509 certificates are widely used in many Internet protocols such as TLS or SSL, and are also used in offline applications such as digital signatures.

Although blockchain networks can conduct transactions without third-party intervention, they still rely on the PKI architecture to ensure secure communication between various network participants and to ensure that messages posted on the blockchain are correctly authenticated.

9 shows a transaction operation process of a blockchain network according to the present invention.

The transaction operation process of the blockchain network according to the present invention will be described with reference to FIG. 9. First, the client application user registers and registers with a certification authority (CA) and receives the required number of times, which is used for authentication on the network.

Transaction proposals are constructed by the client application, which sends a request to the target peer by utilizing the application software development kit (SDK). The transaction proposal is a request to trigger a smart contract function for the purpose of reading or updating the ledger.

Endorser peers accept the transaction proposal input as an argument for the called smart contract function. The smart contract is then executed against the defined business logic to derive transaction results in a simulation environment. However, the updated transaction results are not transmitted to the ledger at this time.

A set of response values includes a set of response values, a set of reads, and a set of writes. The read set captures the most recently read data in the current state, and the write set holds the data to be written to the next state when simulating a transaction. In response to the proposal to the client application, a read set and a write set are passed along with a signature. The client application verifies the supporter peer signature and determines whether a predefined approval policy has been implemented before broadcasting the transaction proposal and response to the signer.

Ordainers receive transactions within the network, order them in blocks, and forward these blocks to all committer peers. Each committer peer validates the transaction to ensure that the authorization policy is enforced and that the read set matches the current state.

When the transaction is confirmed, each peer adds the block to the ledger and commits the write set to its current state. Finally, these commit nodes generate an asynchronous event that notifies the client that the transaction has been added to the blockchain, and notifies whether the transaction is validated or not.

In the smart contract-based sharing economy service providing system in the present invention, as shown in FIGS. 1 and 3, changes to contract information, payment information, asset information, and participation information related to smart contracts are stored and updated, It may be configured to further include an off-chain database (FIG. 1: 400) provided to the blockchain network. The off-chain database submits a transaction that collects changes in the participant module to the off-chain database, and the transaction is submitted to the blockchain network, thereby increasing the efficiency of transaction processing.

That is, the off-chain database in the present invention can be used to take the current value of the ledger from the blockchain. That is, the client submits a transaction that collects changes to the off-chain database, and the transaction is committed to the blockchain. The most notable difference between blockchain data structures and off-chain databases is that data is immutable.

Data, once recorded on the ledger, cannot be modified by network administrators on the blockchain.

However, the data stored in the off-chain database 400 is constantly updated whenever the national value changes, such as when ownership of a car is transferred from one place to another.

The off-chain database 400 serves as a database that provides a rich set of operators for efficient storage and retrieval. Blockchain networks can be configured to use different databases to address the needs of different types of values and access patterns required by applications. This approach proposed in the present invention can significantly improve transaction processing performance because it does not need to go through the entire transaction log in the blockchain.

[Example: Implementation of notebook sharing economy service]

Hereinafter, an example of implementing a sharing economy system in which a shared asset according to the present invention is set as a "laptop computer" and shares it will be described. In this embodiment, the function of a smart contract is implemented, but is performed using Hyperledger Composer.

The 'Hyper ledger Fabric Blockchain' network is deployed on Ubuntu Linux v18.04.2 LTS with Intel Core i5-8500 @ 3.00 GHz processor and 12 GB memory. The Docker engine acts as an execution environment and provides tools to configure Docker images and containers in a virtual machine.

The blockchain client application is implemented using the JavaScript SDK and provides a set of APIs for interacting with the deployed business network. VSCode is used as an integrated development environment (IDE) for working with smart contract code.

In addition, in this embodiment, Hyperledger Composer is used to create a REST (Representational State Transfer) server that exposes blockchain logic to a web or mobile application.

REST Server transforms smart contracts for business networks into open API definitions, and supports Create, Read, Update and Delete (CRUD) to perform operations on the blockchain at runtime.

Leveraging Passport.js to gain access to REST network resources authenticates requests through a scalable set of strategies, including the use of usernames and passwords, and the use of third-party services. CouchDB is used as an off-chain database to maintain the current value of the ledger state. It provides rich query support such as "get, put, delete method" that can access an off-chain database through a simple API with a smart contract. The structure of smart contract participants is modeled as shown in Table 1.

[Table 1: Definition of Participants in Smart Contracts]

The hyperledger blockchain network according to this embodiment provides the ability to modify assets using transactions. Table 2 shows the structure of the asset and includes various information about the asset.

[Table 2: Asset Definition of Smart Contract]

Fig. 10 details the SLA specification specified in the notebook sharing application in this embodiment.

Laptop Providers and Consumers are used as the basis of the contract and represent the key stakeholders involved in the SLA.

The SLA contains three states that represent the state of the Service Level Agreement (SLA) lifecycle throughout the lifecycle of a shared service. On the other hand, in the present invention, three different service levels are defined according to the operation level, data storage, and network bandwidth.

The turnaround time (TAT), average cover time (MTTR), and collection period published in FIG. 10 are used as performance indicators in the SLA. Subscription time represents the effective SLA period between the provider and consumer. The Violation field is used to indicate whether a violation has occurred under the terms of the contract, which can only be modified by the validator.

As shown in Table 3, a transaction list for a notebook sharing system is defined in an embodiment of the present invention. Participants can interact with assets through trades. Transactions are limited to designated participants, and they modify resources according to predefined actions. It is necessary to note that business can be equally applied to not only assets but also participants according to business requirements. For example, an “issue token” transaction is used to increase the token balance of a particular consumer participant.

[Table 3: Transaction Definition of Smart Contract]

The transaction process function is the logical operation of the transaction defined in the smart contract as shown in FIG. 11 . The structure of this function includes decorators and metadata followed by JavaScript functions, both of which are necessary for the transaction to work.

As shown in Algorithm 1 shown in Table 4, the pseudo code of the transaction processor function associated with the "Subscribe SLA" transaction is to modify both the SLA asset and the current consumer's state. This transaction is only executed when the status of the SLA is available. It then updates the state of the SLA asset, adds a connection between the SLA asset and the current participant, and emits an event.

[Table 4: Transaction process function for SLA subscription]

12 shows the interaction between the blockchain and the off-chain database. An off-chain database contains one SLA asset, which is represented as a key-value pair. In contrast to an off-chain database, a blockchain is a transaction log that records all changes that reflect an off-chain database.

Transactions are arranged in blocks in chronological order, and these blocks are cryptographically linked to each other to form a chain sequence, allowing users to see historical changes that have occurred in the data lake rather than the chain.

In a real production environment, real-time data from an asset is needed to determine whether a breach occurred during the duration of an SLA contract. In embodiments of the present invention, monitoring of assets is not considered to simplify operations.

13 shows a simplified workflow of a notebook sharing case study to which an embodiment of the present invention is applied.

In a realizable network, all participants in the system must obtain a certificate containing identity information and a connection file before connecting to the system.

This certificate is issued through a registration and registration process that only system administrators can perform. The provider can register the notebook's basic information, including the model name, manufacturer, and other specifications of the notebook. Of course, in this case, it is preferable to configure the required level of service specifically requested by the consumer separately from the scope of the general service level agreement that the provider can provide.

That is, after the provider registers the information of the thing (laptop), the provider can define the SLA, and it is necessary to verify the format of the SLA before the consumer sees the document.

Issuers issue tokens to consumers as additional steps require tokens. Consumers sign up for an SLA and rent a laptop.

At this stage, the consumer transfers a certain number of tokens to the provider according to the service level. These consumer service level agreements may vary depending on the degree of interest expressed according to various consumer situations, and the level of the agreement (VIP-Diamond -Platinum, etc.) to provide a customized level of service provision (secrecy level, data security, reliability, etc.) something to do.

Consumers can obtain a login password randomly generated by the network and use the obtained password to access the laptop. During the term of the contract, the consumer can submit a problem to the network if a defect occurs. For example, the wireless network connection is lost. The network passes this problem on to a provider who can take action to solve the problem. Provider may modify the status of submitted publications according to actual conditions. The monitor continuously monitors the status and makes decisions accordingly.

In that case, the problem is not resolved according to the business hours defined in the SLA, which may be considered a violation, and the consumer may be compensated. If validation is not detected during the contract and the lease has expired, the consumer can terminate the SLA, revoke the login password again and return the laptop.

In the above-described embodiment of the notebook sharing system of the present invention, the REST Server is configured to authenticate the client using the Gitub authentication provider.

As shown in Fig. 14, the client must authenticate to the REST Server before access to the business network resource protected by the OAuth2.0 scheme is allowed.

The service owner (Github account) can obtain consent for the client application. The Gitub authentication server requests the consent of the service owner and issues an access token to the client. The issued access token is stored in the web browser's local storage.

When the user initiates a subsequent request, the client validates the access token retrieved from local storage instead of re-authenticating the user. Moreover, the REST Server itself is configured to hold the business network cards needed to connect to the blockchain network. These business network cards are IDs issued using Fabric-CA server to register enrollment certificates. Each ID has a standard structure consisting of a descriptive label, an X.509 certificate containing a public key, a private key, and some fabric-specific metadata.

For example, referring to the sample participant certificate shown in FIG. 15 , for example, the sample certificate includes a digital certificate describing a participant named 'Jack'. This certificate includes identification information such as the PKI that issued the certificate, the date of creation of the certificate, and the validity period of the certificate. The highlighted subject text provides key facts about Jack and also contains a lot of information. It is noteworthy that Jack's public key is distributed in his certificate. However, his private signing key remains private.

16 is an image showing the results of the above-described notebook sharing case, and what is shown is the implementation result presented in the Hyperledger Composer Playground.

It is a web user interface that tests the business logic of a smart contract executed in the Hyperledger Fabric runtime. As shown in FIG. 16, the playground wallet contains a series of IDs issued by Fabric CA, respectively.

Figure 17 shows the Composer REST Server Explorer used to inspect and test the generated REST API. The smart contract model for the business network is translated into an Open API definition, which implements create, read, update and delete operations so that transactions can be processed or retrieved at runtime. When the client authenticates the REST Server, the explorer redirects the request to the Gitub authentication provider. The authentication provider then redirects back to the REST server to display the access token at the top of the page. The access token can be passed in the REST request to authenticate the client.

18 shows an image of the above-mentioned playground wallet API, (a) a wallet API specification, and (b) an image in which a business network card is added to payment.

In other words, when a client authenticates the REST API, that client can add an ID to the wallet. The wallet is private to the customer and inaccessible to other customers. When a client makes a request to the REST Server, it uses the ID in the client's wallet to digitally sign all transactions performed by that client. In order to add an ID to the wallet, you need to move to the wallet API by expanding the wallet category as shown in FIG. 18 (a). The ID card can be imported into the wallet by calling POST/wallet/import operation as shown in Figure 16b.

19 shows a transaction test of Composer REST Server. It can verify that the participant connects to the business network by calling the following API: As shown in Fig. 19, the business network is accessed by returning the information of the current participant and the relevant ID in the corresponding subject.

Fig. 20 (a) is a snapshot of the provider profile defined in the smart contract, and the consumer profile is presented in Fig. 20 (b). The specification of the SLA generated by the provider is shown in Fig. 20 (c).

21 shows a snapshot of the transaction record of the Composer Playground, including date, input type and participant. “Date” is an immutable blockchain ledger record time indicating when a transaction was executed. "Entry Type" indicates the transaction type and "Participant" indicates the current participant submitting the transaction. The dashboard also provides items that show the details of the transaction.

[Experimental example: Performance evaluation of blockchain network sharing economy system]

Hereinafter, experimental results for evaluating the performance of the system of the present invention are presented.

The prototype blockchain network in this experiment consists of 4 peers and 1 orderer. The term transactions per second (tps) refers to the number of transactions performed by a blockchain network per second, also known as throughput. For this analysis, we used the Hyperledger Caliper as our benchmark simulation tool. The configuration script was modified to simulate the behavior of the case study for performance evaluation.

For the first experiment, we evaluated the throughput of the proposed system by varying the transmission rate from 200 tps to 1300 tps. Throughput can be classified into two categories: read throughput and transaction throughput. Read throughput measures the number of read operations that are completed in a defined time period. Transaction throughput measures the number of valid transactions executed on the blockchain within the allotted time.

The formulas for these two indicators are presented in Equations (1) and (2), respectively. Note that the total number of invalid transactions must be subtracted from the total to yield the total valid transactions. The average read throughput of the proposed system was evaluated by changing the transmission speed from 500 tps to 3000 tps at a randomly selected system utilization level, and the experimental results are shown in FIG. 22 . Read throughput increases until it peaks at 2346 tps with a transfer rate of 2500 tps. Therefore, in the case of the proposed network, the optimal transmission rate for read throughput is obtained as 2500 tps. As in FIG. 23 , the optimal transfer rate of the transaction throughput is 1100 tps, since the throughput continuously decreases as the transfer rate increases thereafter.

In addition, another study on network latency was performed to indicate how long it takes for a transaction to execute on a blockchain network.

As with the first experiment, latency falls into two categories: read latency and transaction latency.

Read latency refers to the time at which a read request is submitted and the time at which a response is received. Transaction latency is a network-wide representation of how long it takes to execute a transaction over the network. Measurements include not only time from the time of submission, but also broadcast time and revision time, since consensus mechanisms are in place.

Eyal et al. proposed a useful definition of a network threshold, which is the ratio of networks it takes to define a network threshold. In this experiment, after using a non-stochastic protocol such as PBFT, the ratio of the network was set to 100%.

The general and simplified formulas for calculating read latency and transaction latency are shown separately in equations (3) and (4).

The average read delay time of the proposed system as shown in FIG. 24 was evaluated by changing the transmission speed from 500 tps to 3000 tps 10 times at a randomly selected system resource utilization level. The read latency increases relatively small as the transfer rate increases. However, after exceeding the optimum value, if the transmission speed exceeds 2500, the waiting time increases significantly. Similarly, the graph in Figure 23 shows that the average transaction latency increases linearly as the user request rate increases, and this value sharply increases after the optimal transfer rate of 1100 tps.

In general, Bitcoin takes close to 10 minutes to mine a block, and since a transaction requires at least 6 confirmations before it is confirmed, you can expect a transaction to take an average of an hour or so. In the case of Ethereum, the average transaction time to mine one block is about 15 seconds. Moreover, this time cost is quite different in terms of the network environment. According to Figure 21, the average transaction latency of the proposed blockchain network is about 2.3 seconds, well ahead of most popular blockchain platforms. Behind the scenes, the reasons vary depending on the nature of the blockchain, which directly affects transaction performance. Bitcoin and Ethereum are permissionless blockchains that anyone can participate in, and all participants are anonymous.

To establish trust among anonymous participants, permissionless blockchains employ unique cryptocurrencies or transaction fees to provide economic incentives to offset the extraordinary cost of verifying transactions, typically based on proof of work (PoW). do. On the other hand, the proposed blockchain is built based on a permissioned network, where transactions are operated between known and identified participants according to the governance model. By relying on participant identities, permissioned blockchains can use more traditional PBFT protocols that do not require expensive mining.

In addition, permissioned blockchains can reduce the risk of participants intentionally introducing malicious code through smart contracts. Since the participants know each other and all actions are taken, the submission of application transactions, modifications to the network configuration, are recorded on the blockchain according to the authorization policies set for the network and related transaction types. As a result, all guilty parties can be easily identified, and the case is handled according to the conditions of the domination model.

Another experiment on resource utilization of blockchain network using Hyperledger Caliper was performed with 5 iterations. The resource utilization test results explain the maximum average utilization of memory and central processing unit (CPU) as shown in Table 4. For peers, the average memory allocation was recorded at 97.35 MB and the average CPU utility was recorded at 5.77%. For the orderer node, the average memory allocation was recorded at 26.4 MB, and the average CPU utility was recorded at 1.25%. For the CA node, the average memory allocation was recorded at 5.5 MB, and the CPU utility was recorded at 0%. The results of the resource utilization experiment prove that the blockchain network has a low system resource share, high reliability, and comfortable user experience.

[Table 4]

The smart contract-based sharing economy service providing system according to the present invention is based on a smart contract for automatic management of SLA in the sharing economy field. In case of violation of the SLA, the specified subscription fee or monetary compensation is automatically paid. All parties involved will know which company is violating the SLA, and each party will be able to investigate any transaction. Other aspects of SLA management have also been incorporated into approaches such as defining, negotiating and terminating SLAs. The notebook sharing case study is implemented as a proof-of-concept on the proposed architecture using Hyperledger Fabric.

The foregoing description of the present invention is for illustration, and those of ordinary skill in the art to which the present invention pertains can understand that it can be easily modified into other specific forms without changing the technical spirit or essential features of the present invention. will be. Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive.

100: participant module
200: Blockchain Network
300: shared asset DB
400: Off-chain database

Claims (6)

delete delete In a sharing economy system that performs a service contract for a shared asset under wired/wireless communication and executes asset sharing by accessing a blockchain network in which the service contract information is registered,
The sharing economy system includes a plurality of participant modules, the participant module comprising:
A provider module that provides a solution or service asset based on the service level agreement template, but provides a smart contract including things, shared services, and security levels provided according to the service level agreement;
a validator module for verifying the validity of a smart contract based on a service level contract template registered by the provider on a blockchain network;
In order to use the shared assets according to the smart contract, check the smart contract-related validation results, sign a contract for the use of the shared assets, and provide objects, shared services, and security ratings according to the service level agreement. a consumer module that provides a matching token to the provider module;
a monitor module for monitoring compliance with contract standards included in the smart contract, inspecting compliance with guarantees for service use, and executing penalties as compensation measures specified in the smart contract in case of violation;
An issuer module generated by tokenizing the value of the service asset related to the smart contract;
The scope of the monitoring includes the level of service requested by the consumer in the contract, whether the contract is fulfilled, security, data security and shared service level,
The blockchain network is
a smart contract registration unit in which information on which a smart contract concluded between the provider module and the consumer module is approved is registered on the block chain network;
a distributed ledger generating unit that blocks the smart contract-related information and implements a distributed ledger to be shared with users on a network;
an ID authentication unit for authenticating access rights of subjects accessing the distributed ledger;
a verification unit that verifies the validity of the smart contract through the verifier module;
an event hub for generating an event to a client or triggering a transaction defined in a smart contract when a new block is added to the distributed ledger;
an API interface unit that exposes the services provided by the blockchain network as an open API system for client applications to interact with smart contracts;
A defect correction unit that verifies the validity of the information written in the distributed ledger through the Byzantine Fault Tolerance (PBFT) algorithm;
The sharing economy system is
An off-chain database that stores and updates changes to contract information, payment information, asset information, and participation information related to the smart contract, and provides it to the blockchain network;
The off-chain database is
To increase the efficiency of transaction processing by receiving a transaction that collects changes from the participant module and submitting the transaction to the blockchain network,
Smart contract-based sharing economy service provision system in the Internet of Things.
delete delete delete

Images