Patent Application
20200195421
A “distributed ledger” generally refers to a shared digital ledger that is decentralized and shared between nodes distributed across a network. After a transaction that is approved to be written to the ledger is consented by at least the majority of the nodes, the contents of the ledger are synchronized across all the nodes. One presently popular type of distributed ledger technology is blockchain technology. While in a distributed ledger a transaction is written to the ledger after consensus, the requirement is more specific in a blockchain: transactions are aggregated in to a block and the block is appended to the last block of an existing linear chain of blocks. Blockchain technology is presently popular in the use of cryptocurrencies and development of decentralized applications. BITCOIN and ETHEREUM are examples of blockchain-based platforms.
Different types of consensus mechanisms such as proof of work and proof of stake that bring in varying levels of processing requirements to agree on a transaction amongst distributed nodes may be utilized in a blockchain network. A common technique used in such consensus mechanisms is a process referred to as “mining” by which new transactions are validated and recorded in a block using a computational resource. For example, in the case of proof work, miners compete for a reward to be the first to solve a computationally expensive mathematical problem based on a cryptographic hash algorithm that may increase in complexity as the blockchain grows. The solution may be referred to as a “proof of work,” signifying that the miner spent substantial computational resources solving the problem. The term “mining” derives from the fact that the proof of work is solved by repeated trial and error, referred to as “hammering away” at the problem until a solution is found. After a solution is found, the blockchain transactions may be considered confirmed and a new block may be added to the blockchain network.
The present disclosure, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict typical or example embodiments.
The figures are not intended to be exhaustive or to limit various embodiments to the precise form disclosed.
As used herein, the term “blockchain mining” refers to using one or more of a processing resource or memory resource of a device as part of a blockchain consensus protocol in an attempt to verify one or more blockchain transactions that are written to a block of a blockchain. For example, blockchain mining may use a processor and/or memory of a user device as part of a proof-of-work, proof-of-space, proof-of-time, proof-of-stake, or some other blockchain consensus protocol. In some specific implementations, blockchain mining may refer to using computational resources of a user device to compute one or more cryptographic hashes as part of a consensus protocol such as proof of work.
As used herein, the terms “hashing,” “computing a hash,” and like terms or phrases refer to taking a byte array and applying a cryptographic hashing function to the byte array to transform that byte array to non-predictable deterministic fixed-size bytes.
Various implementations of the disclosure are directed to providing network access to a user device through an access point in exchange for blockchain mining. Some particular implementations are directed to installing an application on the user device for providing Internet access in exchange for blockchain mining. Other particular implementations are directed to utilizing the user device's OS to obtain Internet access in exchange for blockchain mining. As will be appreciated by the forthcoming discussion, various technical advantages may be achieved by virtue of the implementations described herein. For example, the technology disclosed herein may be used to utilize underused processors and/or memory devices of a user device to obtain free Internet access while providing an AP provider with the benefit of blockchain mining (e.g., cryptocurrency rewards, transaction rewards, or some other reward for mining a block). Further, in implementations where a consensus protocol that requires hashing is used, the technology disclosed herein may provide the flexibility to hash any type of blockchain and to adjust a hashing rate.
It should be appreciated that although a single user device 100 and AP 200 are shown in this environment, multiple user devices 100 may connect to an AP 200 to access the Internet 150 in exchange for blockchain mining. Additionally, multiple APs may be present in this environment, in which case some or all of the APs may provide Internet access in exchange for blockchain mining. Furthermore, although a single blockchain network 300 containing a copy of a blockchain 320 that is propagated to blockchain nodes 310 is illustrated in this example, in some implementations an AP 200 may be capable of assigning a user device 100 a blockchain mining task for a plurality of different blockchains. For instance, an AP 200 may be capable of assigning a user device 100 to mine for one of a plurality of cryptocurrencies such as ether and bitcoin. Moreover, it should be appreciated that although implementations of the disclosure will be primarily described in the context of providing Internet access in exchange for blockchain mining, implementations described herein may more generally apply to providing access to any network in exchange for blockchain mining. For example, access to a content delivery network (e.g., to view television series or movies), an intranet, a local area network, or any other suitable network may be provided in exchange for blockchain mining.
As illustrated in
AP 200 may refer to hardware networking device that allows one or more user devices 100 to gain access to a network (e.g., Internet 150). For example, AP 200 may be implemented as an IEEE 802.11 AP that connects a WIFI device to a wired network such as a wired LAN. In the example of
As noted above, in the environment of
Blockchain network 300 may be any blockchain network that implements mining as part of its consensus mechanism (e.g., as part of a proof of work, proof of space, proof of stake, etc.) for verifying blockchain transactions that are added to blockchain 320. In some implementations, the blockchain 320 of blockchain network 300 may provide a record of transactions involving cryptocurrencies. In other implementations, the blockchain 320 may provide a record of other types of transactions. Blockchain network 300 may include a plurality of blockchain nodes 310 that may validate transactions. Some or all blockchain nodes 310 may store a respective copy of a blockchain 320 that contains a chronologically ordered, back-linked list of blocks.
In the example of
To illustrate one particular example of blockchain mining, consider the case where blockchain 320 corresponds to the BITCOIN blockchain. In this example, transactions may be collected from a transaction pool to build a candidate block. A Merkle Root hash may be calculated for all of the transactions. Thereafter, a block header may be created by combining the current blockchain version, the previous block's hash, the Merkle Root hash, the current time, difficulty bits (current difficulty level), and a nonce. In this context, the nonce may refer to a placeholder for a random number to be tried in order to create a new hash from the same candidate block. A blockchain mining hash may be calculated by applying a SHA-256 hashing algorithm twice to the block header. If the mining hash has a certain number of leading zeros (e.g., depending on difficulty level), the hash may be considered successful. Otherwise, the above process may repeat using a new nonce. Once a nonce in the candidate block makes a hash with enough leading zeros (i.e., a winning block is found), the block may be sent to all participating nodes for consensus, and the node may be rewarded for adding the block.
It should be emphasized that although the above example illustrates the operation of blockchain mining in the context of BITCOIN, implementations described herein may be used with any blockchain protocol that uses a mining consensus mechanism that relies on processing and/or memory resources of a device to verify one or more blockchain transactions that are written to a blockchain. For example, in implementations where the blockchain uses a proof-of-space consensus protocol, blockchain may comprises the user device allocating memory or disk space to solve a challenge. As such, the implementations described herein need not be limited to blockchain mining that relies on computational power to compute hashes.
Machine readable medium 110 may store various instructions that may be executed by processing device 120 to implement various embodiments in accordance with the disclosure. For example, machine readable medium 110 may store instructions 111 for discovering and connecting to APs, instructions 112 for retrieving an application (e.g., MFIA application 115) that enables mining for Internet access (MFIA), and instructions 113 for accessing Internet content. Machine readable medium 110 may also store an MFIA application 115 that may be retrieved from an App store and run by user device 100 to perform blockchain mining tasks for an AP 200 in exchange for Internet access. MFIA application 115 may include instructions 116 for requesting and receiving a blockchain mining task, and instructions 117 for performing a blockchain mining task. In alternative implementations, instructions 116-117 may be natively incorporated into the operating system (OS) of the device.
Display 130 may be to display wireless APs that are available to connect to, to display data retrieved over the Internet, to display data relating to blockchain mining (e.g., through an application 115), and to display other data.
Machine readable medium 210 may store various instructions that may be executed by processing device 220 to implement various embodiments in accordance with the disclosure. For example, machine readable medium 210 may store instructions 211 for transmitting a beacon and connecting to user devices 100, instructions 212 for forwarding a blockchain mining task for a user device 100, and instructions 213 for providing a user device 100 with Internet access. In some implementations, the AP 200 may also include instructions for creating the blockchain mining task. Alternatively, the instructions for creating the blockchain mining task may reside in a controller 350 separate from AP 200, and in such implementations the AP 200 may function to forward the mining task created by the controller 350. More generally, it should be appreciated that the tasks described herein as being performed by AP 200 may be performed by controller 350 or some other device.
At operation 510, the mobile device displays a list of accessible APs 510. For instance, as illustrated by the particular example of GUI 415, a list of various accessible wireless APs may be displayed. In some instances, the APs that provide MFIA may have some type of indicator or icon that identify them as having this feature in the list of accessible wireless APs that is displayed.
At operation 520, an AP having a MFIA feature is selected by the user. For example, the user may tap the touchscreen of the user device to select one of the listed wireless APs. At operation 530, in response to the user selecting an AP having an MFIA feature, the OS of the user device 100 presents a notification of the selection of an AP that provides MFIA. For instance, continuing the previous example of GUI 415, a warning 435 may be displayed to the user that in order to browse the Internet with the selected AP, the user device 100 will having to perform calculations that use up battery life and/or cause the device to run hotter. Warning 435 just provides one example of the types of notifications that may be displayed to the user in response to selecting an AP with MFIA. As would be appreciated, by virtue of displaying the advance warning to the user, the process flow ensures that the user's participation in blockchain mining is voluntary. At operation 540, the user provides confirmation that the user wishes to proceed with the connection.
Following confirmation, at operation 550 the user device may connect to the Internet by implementing MFIA through the OS of the user device. Information, settings, and warnings related to MFIA may be implemented through the OS in various ways. Particular example implementations of operation 550 are further described below.
Operations 510-520 of method 600 may be implemented in the same manner as described above with reference to method 500. At operation 610, the user device connects to the AP. For example, the user device may transmit an association request to the wireless AP and receive back an association response from the wireless AP. At operation 620, after connecting to the wireless AP, the user device may test its Internet connection (e.g., by attempting to access a web domain) and be redirected to a captive portal of the AP. A captive portal may refer to a web page that is displayed on a newly connected user device before users of the device are granted access to network resources (e.g., to the Internet) through the AP.
At operation 630, the user device displays the captive portal that it was redirected to, where the displayed captive portal includes an option to download an application for MFIA. For instance, as shown by the particular example of captive portal webpage 635, the captive portal may display a notification 636 that WIFI access will impact device speed and/or battery because the device is being used to compute data (e.g., compute hashes for mining), store data, or use some type of processing or memory resource. Additionally, example captive portal webpage 635 displays a control 637 that may be selected (e.g., through a touch user interface gesture) to download an application for blockchain mining in exchange for Internet access. For example, selecting control 637 may redirect the user device to download an MFIA application 115 through an appstore. For instance, depending on the OS of the user's device. As another example, control 637 or some other part of webpage 635 may include a direct software download link for the application that can be accessed by user device 120.
At operation 640, after user selection of the control for downloading the MFIA application (e.g., control 637), the application may be downloaded, installed, and initialized. The AP may permit the user device to access the appstore in order to download the application. At operation 650, following initialization of the application, the user device may connect to the Internet by implementing MFIA through the application. Information, settings, and warnings related to MFIA may be implemented through the application in various ways. Particular example implementations of operation 650 are further described below.
At operation 710, the user device 100 transmits a request to a networked device (e.g., AP 200 or controller 350) for a blockchain mining task. The blockchain mining task may specify the utilization of the user's device processor and/or storage device based on a blockchain consensus protocol to verify one or more blockchain transactions that are written to a blockchain. For instance, in specific implementations the blockchain mining task includes one or more values to hash and a hashing technique to use. In various implementations, prior to requesting the blockchain mining task, the user device 100 may first query the AP 200 or controller 350 to determine a balance of data (e.g., in bytes) available to access the computer network. If the balance of data falls below a predetermined threshold (e.g., a value indicating that interruption of service is imminent), the user device 100 may make the request for a mining task. As such, the user device 100 may be configured to periodically poll the AP 200 or controller 350 for a data balance (e.g., in bytes) to determine when additional blockchain mining is needed to sustain the connection to the network. As part of the periodic poll, the user device may also request the hash rate per bytes.
At operation 720, in response to transmitting the request, the user device 100 receives a blockchain mining task. In various implementations, the received blockchain mining task may include one or more values to hash and a hashing technique to be used. For instance, in particular implementations the blockchain mining task may identify a value along with a range of nonces to append to the value and hash. The hashing technique may depend on the blockchain protocol. For example, SHA-256 hashing (e.g., in the case of BITCOIN), Keccak hashing (e.g., in the case of ETHEREUM), or some other hashing technique may be used depending on the blockchain protocol.
At operation 730, the user device may perform the blockchain mining task. For example, the user device may compute the hash of one or more values using an appropriate hashing technique (e.g., as identified by the AP 200 and/or controller 350). As the user device computes hashes, it may periodically send all or a subset of the computed hashes to the AP to verify that the user device is performing the mining task (in this e.g., hashing). For example, the computing device may send all hashes, a lowest (e.g., with most leading zeroes) computed hash of a batch (e.g., every 100) hashes, hashes that fall below a predetermined threshold, etc. As more hashes are computed and sent, the user device's data balance allocated or awarded by AP 200 and/or controller 350 to access a network (e.g., the Internet) may increase. For example, for every 100 hashes computed by a smartphone, the smartphone may be awarded 1 megabyte of data to access the Internet. In some implementations, the user device may compute and send hashes until the data balance achieves a certain buffer size (e.g., x megabytes). Thereafter, the user device may pause hashing. Alternatively, the user device may continue hashing throughout the time that it is connected to AP 200 without a buffer.
At operation 740, the user device accesses a computer network (e.g., Internet) through the AP using data awarded (e.g., by the AP or a controller connected to the AP) in response to performing the blockchain mining task.
Although method 700 was described in the context of the user device 100 periodically polling a networked device to retrieve information such as a blockchain mining task, a balance of data available to access the network, and a hash rate per bytes, in alternative implementations this information may be periodically pushed from the networked device to the user device 100. As such, it should be appreciated that updates may be pulled and/or pushed using an application installed on the user device and/or the OS of the user device.
At operation 810, an AP of a wireless network access system broadcasts a beacon identifying the AP as an AP that provides Internet access in exchange for blockchain mining. For example, the AP may broadcast a beacon comprising a bit that provides an indication that the AP provides Internet access in exchange for blockchain mining. In particular implementations, the bit providing the indication may be specified as part of the 802.11 specification, or it may be specified in a vendor-specific field.
At operation 820, the AP connects to the user device. In implementations where the user device's OS does not natively support blockchain mining in exchange for Internet access, the wireless network access system may redirect the user device to a captive portal that directs the user to download an application (e.g., app 115) for blockchain mining in exchange for Internet access. In such implementations, once the user device initializes the app and performs a handshake with the wireless network access system to initiate mining for Internet access, the captive portal may be removed, and follow-up information such as the user device's remaining data balance may be provided via notifications in the running app.
At operation 830, the wireless network access system receives a request from the user device for a blockchain mining task. In response to the request, at operation 840 the wireless network access system transmits a blockchain mining task (e.g., values to hash and hashing technique) to the user device. In some implementations, the wireless network access system may also transmit a remaining data balance for the user device to access the network. In implementations involving blockchain mining based on hashing, a hash rate in bytes may also be transmitted to the user device.
At operation 850, the wireless network access system awards/allocates data to the user device to access the computer network (e.g., Internet) in response to the user device performing the blockchain mining task. For example, as the user device sends hashes as a part of a proof-of-work algorithm, or stores data as part of a proof-of-space algorithm, the wireless network access system may award data for the user device to access the Internet. At operation 860, the wireless network access system may use the awarded data to provide the user device with access to the computer network (e.g., Internet) as the user device attempts to access the network through the AP. It should be appreciated that operations 830-860 may be iteratively be repeated over time to provide the user device with access to the Internet in exchange for blockchain mining.
Although method 800 was described in the context of the wireless network access system being polled by user device 100 to retrieve information such as a blockchain mining task, a balance of data available to access the network, and other data (e.g., a hash rate per bytes), in alternative implementations this information may be periodically pushed from the wireless network access system to the user device 100.
As illustrated, at step 901 the user device 100 may scan for APs that provide a WIFI connection. At step 902, an AP 200 transmits a beacon including a bit indicating that mining for Internet access is enabled. At step 903, a user of user device 903 selects the WIFI corresponding to AP 200. At step 904, the OS of the user device presents a message indicating that the selected WIFI will require blockchain mining.
At step 905 the user device initiates the connection to the system 1100. During the connection process, an association request 906 is sent, an association response is received (step 907), and the OS engages in a MFIA handshake (step 908) with the system 1100. At step 909, the user device 100 may test for a captive portal. In this example, by virtue of having already performed the handshake, system 1100 may skip the step of redirecting user device 100 to the captive portal with the link to app installation. Alternatively, in other implementations a captive portal may be presented (e.g., to present terms and conditions to the user).
Thereafter, an iterative process for mining in exchange for Internet access may be performed between user device 100 and system 1100. In this example, the iterative process is implemented through the OS of user device 100. As part of that iterative process, user device 100 may query for a remaining data balance (step 910), receive back the remaining balance from system 1100 (step 911), determine if the data balance falls below a threshold (step 912), and if it does fall below that threshold, request and receive a mining task (steps 913-914) to be performed to increase the data balance.
The loop for MFIA may terminate after the user device 100 disconnects from system 1100 (step 915), at which point a disassociation request may be sent (step 916), and a disassociation response may be received (step 917).
In this example, after the user device 100 tests for a captive portal (step 909), at step 1001 the user device 100 sends a request to system 1100 to retrieve a website. In response, the system 1100 redirects user device 100 to a Captive Portal at step 1002. At step 1003, the user device 100 presents a captive portal including an option for downloading an application that enables blockchain mining in exchange for Internet access. After the application is selected for download (step 1004), the system 1100 permits traffic to an appstore to enable the download (step 1005). Thereafter, the application is installed (step 1006), opened (step 1007), and the application engages in a handshake with system 1100 to initialize mining for Internet access (step 1008). The system 1100 removes the captive portal, and subsequent information relating to mining and Internet access may be shown through the application that was opened (step 1009). For example, the app may present notifications to the user and/or may display information when it is opened.
Thereafter, an iterative process for mining in exchange for Internet access may be performed between user device 100 and system 1100. In this example, the iterative process is implemented through the opened application. As part of that iterative process, user device 100 may query for a remaining data balance (step 1010), receive back the remaining balance from system 1100 (step 1011), determine if the data balance falls below a threshold (step 1012), and if it does fall below that threshold, request and receive a mining task (steps 1013-1014) to be performed to increase the data balance. The loop for MFIA may terminate after the user device 100 disconnects from system 1100 (step 915), at which point a disassociation request may be sent (step 916), and a disassociation response may be received (step 917).
In this document, the terms “machine readable medium,” “computer readable medium,” and similar terms are used to generally refer to non-transitory mediums, volatile or non-volatile, that store data and/or instructions that cause a machine to operate in a specific fashion. Common forms of machine readable media include, for example, a hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, an optical disc or any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, and networked versions of the same.
These and other various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on the medium, are generally referred to as “instructions” or “code.” Instructions may be grouped in the form of computer programs or other groupings. When executed, such instructions may enable a processing device to perform features or functions of the present application as discussed herein.
In this document, a “processing device” may be implemented as a single processor that performs processing operations or a combination of specialized and/or general-purpose processors that perform processing operations. A processing device may include a CPU, GPU, APU, DSP, FPGA, ASIC, SOC, and/or other processing circuitry.
The various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives can be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration.
Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code components executed by one or more computer systems or computer processors comprising computer hardware. The one or more computer systems or computer processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The various features and processes described above may be used independently of one another, or may be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. Additionally, unless the context dictates otherwise, the methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate, or may be performed in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The performance of certain of the operations or processes may be distributed among computer systems or computers processors, not only residing within a single machine, but deployed across a number of machines.
As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, the description of resources, operations, or structures in the singular shall not be read to exclude the plural. Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps.
Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. Adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known,” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.
