Peer to peer transfer of proof of space plots to or from solid state drives

- Micron Technology, Inc.

An apparatus with a solid state drive (SSD) having firmware to perform peer to peer transfer of proof of space plots. The SSD has a host interface configured to receive at least read commands and write commands from an external host system. The SSD has memory cells formed on at least one integrated circuit die, and a processing device configured to control executions of the read commands to retrieve data from the memory cells and executions the write commands to store data into the memory cells. The firmware is executable in the SSD according to configuration data to: identify an opportunity for a transfer of a proof of space plot; establish a peer to peer connection to a device that is separate from the solid state drive; and transfer, over the peer to peer connection, the proof of space plot between the solid state drive and the device.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
TECHNICAL FIELD

At least some embodiments disclosed herein relate to memory systems in general, and more particularly, but not limited to memory systems configured to support proof of space activities.

BACKGROUND

A memory sub-system can include one or more memory devices that store data. The memory devices can be, for example, non-volatile memory devices and volatile memory devices. In general, a host system can utilize a memory sub-system to store data at the memory devices and to retrieve data from the memory devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

FIG. 1 illustrates an example computing system having a memory sub-system in accordance with some embodiments of the present disclosure.

FIG. 2 shows a memory sub-system having firmware to manage storage space to support proof of space activities according to one embodiment.

FIG. 3 shows a memory sub-system having a proof of space manager configured to perform peer to peer transfer of proof of space plots according to one embodiment.

FIG. 4 illustrates memory sub-systems configured for peer to peer transfer of proof of space plots over a peripheral bus according to one embodiment.

FIG. 5 illustrates a memory sub-system configured for peer to peer transfer of proof of space plots over a local area network according to one embodiment.

FIG. 6 illustrates a memory sub-system configured in a peer to peer network to facilitate transfer of proof of space plots according to one embodiment.

FIG. 7 shows a method to perform peer to peer transfer of a proof of space plot according to one embodiment.

FIG. 8 is a block diagram of an example computer system in which embodiments of the present disclosure can operate.

 DETAILED DESCRIPTION

At least some aspects of the present disclosure are directed to a memory sub-system configured to perform peer to peer transfer of proof of space plots. Examples of storage devices and memory modules are described below in conjunction with FIG. 1. In general, a host system can utilize a memory sub-system that includes one or more components, such as memory devices that store data. The host system can provide data to be stored at the memory sub-system and can request data to be retrieved from the memory sub-system.

A conventional memory sub-system, such as a hard disk drive (HDD) or a solid state drive (SSD), can be used in activities that require the proof of data storage space. There are known types of challenge-response computations that can be implemented via a set of lookup tables. When the lookup tables are stored in the hard drive or solid state drive, a correct response to a challenge can be generated efficiently using the lookup tables with little computing power and energy consumption. Without storing the lookup tables, it can be unfeasible and/or impractical to generate the correct response on the fly within a short period of time. Thus, in response to a challenge, a correct response to the challenge, generated within a threshold period of time from the challenge, can be seen as a result of the response being generated using the lookup tables stored in a data storage device. Storing the lookup tables occupies an amount of data storage space. Thus, the correct response can be used as a proof of the possession of the amount of spare storage space that is currently used to store the lookup tables. A cryptocurrency network can use proof of space (e.g., to replace proof of work used in other cryptocurrency networks, such as Bitcoin) to improve energy efficiency of computations related to cryptocurrency activities. For example, Chia Network uses proof of space and time to replace energy intensive proof of work.

In general, a plot suitable for proof of space includes data used in challenge-response activities. Such data of a plot typically includes a set of lookup tables with numbers that appear to be random and that are generated from a small amount of initial data. For a given challenge as an input, the lookup tables of the plot can be used to generate a response with very little time and computation and thus little energy expenditure. The correctness of the response can be easily verified using the initial data without the lookup tables. However, it is very difficult and statistically impossible to generate the correct response without the lookup tables. Thus, the correct response can be used as a proof that the response is from an entity having the lookup tables and thus the storage space occupied by the plot of lookup tables. The use of plots to generate responses to proof of space challenges can be referred to as plot farming.

A conventional computer system can have a solid state drive connected to a host system. The host system can send commands to manage and use the storage space provided in the solid state drive. For example, the host system can send a command to the solid state drive to allocate or reserve a portion of the storage capacity of the solid state drive for use. Such a portion can have an identification (e.g., as a namespace or a partition) that establishes a logical address space. The host system can request data to be written at a logical address in the logical address space represented by the identification. For example, after a namespace is created in the solid state drive, the host system can send a write command to request a data item to be written at a logical address in the namespace. The logical address is specific to the namespace and independent of other namespaces. The solid state drive maps the logical address in the namespace to a physical address in the solid state drive to execute the write command. To support proof of space activities, the host system can send commands to the solid state drive to manage storage resources, including allocating storage resources to store proof of space plots, freeing the storage resources used by plots for use by other applications. Since proof of space plots are used to store proof of space look up tables and make the storage resources unusable to a host system, an advantage is recognized in configuring the solid state drive to transfer proof of space plots through peer to peer connection with reduced usage of, or without the usage of, resources of the host system and/or a server system.

At least some aspects of the present disclosure address the above and other deficiencies and challenges by configuring a memory sub-system, such as a solid state drive, to perform peer to peer transfer of proof of space plots to and/or from the memory sub-system.

For example, after the memory sub-system is configured with a permission/authorization, the memory sub-system can use a peer to peer connection to automatically transmit a plot from its storage space to another device. For example, the memory sub-system can be used to generate a proof of space plot and use a peer to peer connection to transfer it for storing in another device for farming. For example, a solid state drive can generate proof of space plots and transfer the plots via peer to peer connections to hard drives and/or computing devices for storing and farming. It is faster to generate plots on solid state drives but more cost effective to farm plots on hard disk drives. Thus, when both hard disk drives and solid state drives are available, it can be advantageous to generate plots on solid state drives and transfer them to hard disk drives for farming.

For example, after the memory sub-system is configured with a permission/authorization, the memory sub-system can use a peer to peer connection to automatically receive a plot from another device for storing in the memory sub-system and for farming. For example, when another device having a proof of space plot is to reclaim the storage space occupied by the plot, the memory sub-system can use a peer to peer connection to receive the proof of space plot for storage and/or farming. The transfer can be performed to avoid the destruction of the proof of space plot and/or avoid the need to separate generate a replacement plot. For example, when the storage space in a hard drive currently being used for farming a plot is to be used for an application running in its host system, a solid state drive having a spare storage space can receive the proof of space plot via a peer to peer connection to avoid the need to independently generate a proof of space plot. The solid state drive can subsequently transfer the plot, via a peer to peer connection, to another device, or farm the plot in a cryptocurrency network.

For example, after being permitted to perform the transfer, a memory sub-system, such as a solid state drive, can control a network interface card and/or a communication device to transfer the plot data to or from another storage device or computing device, without using the system memory of a computing system in which the memory sub-system is installed. The transfer can be set up and/or performed without assistance from a host system and/or without the memory sub-system being connected to a host system.

The resources used for the peer to peer transfer of proof of space plots can be limited by configuration parameters stored in the memory sub-system. For example, the network bandwidth used for the peer to peer transfer can be limited by a configuration parameter; and the read/write bandwidth of the memory sub-system used in the peer to peer transfer can be limited by another configuration parameter. The permission and/or restrictions can be configured such that the impact of the transfer on the performance of the memory sub-system in servicing the host system connected to the host interface of the memory sub-system is reduced or minimized. In some implementations, the transfer can be allowed and/or scheduled at a time the memory sub-system is not actively used by its host system. The configuration parameters can be specified via an administrative control panel running as an application in the host system, or over a computer network.

The memory sub-system can have a space manager that automatically organizes storage resources unused by the host system to support proof of space activities.

For example, when there are storage resources that are not yet allocated to host namespaces that are created in response to commands received from the host system, the memory sub-system can be configured to automatically create plot namespaces to store proof of space plots and support proof of space activities.

The plot namespaces, created by the memory sub-system to store proof of space plots, can be configured to be invisible and/or inaccessible to the host system. Thus, the host system can be isolated from the proof of space activities and data (e.g., cryptocurrency data and associated activities). Optionally, the cryptocurrency activities are be configured to be limited within the plot namespaces for improved security of application data of the host system.

Optionally, the memory sub-system can perform the computations to generate a proof of space plot and store the plot in a plot namespace. Alternatively, the memory sub-system can be connected to a peer to peer network to receive the plot from another device to eliminate the need to perform the computations of plot generation. For example, when a device in the peer to peer network is to reclaim the storage space occupied by a proof of space plot, the device can broadcast its availability of the plot for download. In response, the memory sub-system can indicate the availability of storage space for the proof of space plot. After establishing a peer to peer connection, the proof of space plot can be transferred from the device to the memory sub-system at a time and a transfer speed with reduced and/or minimized impact on the host system of the memory sub-system.

Similarly, when the plot namespace in the memory sub-system is to be reclaimed for use by the host system or for another task, the proof of space plot in the plot namespace can be transferred to another device, instead of being erased. The memory sub-system can indicate to the peer to peer network the availability of the proof of space plot; and a device having a sufficient spare storage space can indicate the availability of the space to host the proof of space plot. After establishing a peer to peer connection, the proof of space plot can be transferred from the plot namespace of the memory sub-system to the device. The transfer time and the transfer speed can be scheduled and/or selected to reduce and/or minimize the impact of the transfer on the host system of the memory sub-system.

Optionally, in some implementations, a memory sub-system can be connected to the peer to peer network of storage devices to host and/or transfer proof of space plots even without a host system being connected to the host interface of the memory sub-system.

In other implementations, the host system can run an application to set up and/or control the peer to peer transfers of proof of space plots.

The memory sub-system can manage the storage resources in the plot namespaces and free storage resources that have not yet been allocated to namespaces to meet the storage requests from the host system. In some embodiments, from the point of view of the host system, the storage resources allocated to the plot namespaces can appear to the host system to be the same as free storage resources that have not yet been allocated to any namespaces; and in other embodiments, the plot namespaces allocated by the memory sub-system (and thus not by the host system) are invisible to the host system (e.g., when the host system is connected to the memory sub-system via NVMe). When additional storage resources are to be used by the host system, the memory sub-system can automatically provide the resources from the pool of free storage resources and the storage resources in the plot namespaces. For example, when the currently available free storage resources are insufficient to meet the demand of the host system to create a new namespace or to enlarge an existing namespace, the memory sub-system can delete a plot namespace to return its storage resources as free storage resources.

When the host system sends a command to the memory sub-system to delete a host namespace, the memory sub-system can add to the pool the storage resources reclaimed form the deleted host namespace as free storage resources. When the currently available free storage resources are sufficient to store a proof of space plot, the memory sub-system can allocate free storage resources to create a plot namespace.

Optionally, the host system can send a command to the memory sub-system to create a namespace with an indication that the namespace is created for proof of space activities. In response, the memory sub-system can create and manage the plot namespace for proof of space activities. The command from the host system to create the plot namespace can be configured as a permission for the host system to allow the memory sub-system to participate in proof of space activities using the resources allocated to the plot namespace. When the storage resources of the plot namespace are needed for host namespaces, the memory sub-system can delete the plot namespace without an explicit command from the host system for the destruction of the plot namespace. Optionally, the host system can send a command to explicitly request the destruction/deletion of the plot namespace and thus participate in the management of the plot namespace.

Optionally, the host system can request the memory sub-system to identify plot namespaces present on the memory sub-system and use the plot namespaces to participate in proof of space activities.

In some implementations, the management functions of free storage resources and plot namespaces are implemented at least in part in the host system. For example, a module in the operation system and/or a device driver running in the host system can be configured to manage the free storage resources and plot namespaces such that the remaining operating system and applications running the host system can be free from the handling of the plot namespaces and their storage resources.

Optionally, the memory sub-system can have firmware configured to control proof of spaces activities. For example, a solid state drive (SSD) can be configured with a host interface to provide storage services to a host system in a conventional way. The firmware running in the solid state drive (SSD) can participate in proof of space activities and/or cryptocurrency activities in an autonomous way without the supervision and/or computing resources of an external host system connected to the host interface. For example, in the absence of commands from the host system connected to the host interface, the firmware of the solid state drive can be configured to automatically detect a network connection, generate read/write commands, and perform computations to participate in proof of space activities and/or cryptocurrency activities.

For example, independent of host activities and/or without the host system being active and/or connected to the host interface of the solid state drive (SSD), the firmware can perform tasks such as plot generation, plot farming, peer to peer plot transfer, etc. Thus, the solid state drive (SSD) as a spare component can be used in proof of space before being connected to a host system for normal usage.

The firmware can be configured to use the free space that is not yet used by its host system to generate and/or store one or more plots for proof of space. For example, the firmware can use a plot stored in the memory sub-system (e.g., a hard disk drive (HDD), a solid state drive (SSD), or a memory module) to generate responses for challenges, such as proof of space and time challenges in a cryptocurrency network (e.g., Chia Network, or similar networks).

For improved security, aspects of proof of space activities and/or cryptocurrency activities of the firmware running in the memory sub-system can be configured and/or regulated via configuration data specified using an administrative application. For example, the administrative control of the firmware can be accessed via the host system connected to the host interface of the memory sub-system. Alternatively, or in combination, the administrative control of the firmware can be accessed via a network connection (e.g., without the host system being active or being connected to the host interface).

In some implementations, the memory sub-system can be operational for proof of space activities and/or cryptocurrency activities even without a host system (or with the host system being placed in a sleep mode, a low energy mode, or a hibernation mode). For example, connecting the memory sub-system to a power supply and a network interface card can be sufficient to allow the memory sub-system to operate in a cryptocurrency network. Alternatively, the memory sub-system can be configured to operate in a cryptocurrency network under the condition that the memory sub-system is being connected to a host system that permits the memory sub-system to operate (e.g., when the host system is in an idle state, or independent of the activities of the host system). In some instances, the memory sub-system includes a network interface card, or a wireless transceiver for a network connection to a wireless access point. Thus, before the memory sub-system is installed in a computing system and/or connected to a host system to provide memory and/or storage services for the host system, the firmware of the memory sub-system can allow the free/available storage space of the memory sub-system to be used as a storage appliance in a cryptocurrency network for proof of space.

The memory sub-system can include an internal host configured to reduce the computation burden on the host system connected to the host interface of the memory sub-system. The internal host can be implemented in part via the firmware of the memory sub-system. For example, the host system and the internal host can operate in a collaborative mode where the host system can delegate some or all of the computing tasks to the memory sub-system in activities in a cryptocurrency network.

In general, the administrative control can be used to specify whether the proof of space functionality of the firmware is permitted to run autonomously, how much of the resources the firmware can use and when, what types of activities (e.g., plot generation, plot farming, peer to peer plot transfer) are permitted, etc.

FIG. 1 illustrates an example computing system 100 that includes a memory sub-system 110 in accordance with some embodiments of the present disclosure. The memory sub-system 110 can include media, such as one or more volatile memory devices (e.g., memory device 140), one or more non-volatile memory devices (e.g., memory device 130), or a combination of such.

In general, a memory sub-system 110 can be a storage device, a memory module, or a hybrid of a storage device and memory module. Examples of a storage device include a solid-state drive (SSD), a flash drive, a universal serial bus (USB) flash drive, an embedded Multi-Media Controller (eMMC) drive, a Universal Flash Storage (UFS) drive, a secure digital (SD) card, and a hard disk drive (HDD). Examples of memory modules include a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), and various types of non-volatile dual in-line memory module (NVDIMM).

The computing system 100 can be a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., airplane, drone, train, automobile, or other conveyance), an Internet of Things (I) enabled device, an embedded computer (e.g., one included in a vehicle, industrial equipment, or a networked commercial device), or such a computing device that includes memory and a processing device.

The computing system 100 can include a host system 120 that is coupled to one or more memory sub-systems 110. FIG. 1 illustrates one example of a host system 120 coupled to one memory sub-system 110. As used herein, “coupled to” or “coupled with” generally refers to a connection between components, which can be an indirect communicative connection or direct communicative connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical, optical, magnetic, etc.

For example, the host system 120 can include a processor chipset (e.g., processing device 118) and a software stack executed by the processor chipset. The processor chipset can include one or more cores, one or more caches, a memory controller (e.g., controller 116) (e.g., NVDIMM controller), and a storage protocol controller (e.g., PCIe controller, SATA controller). The host system 120 uses the memory sub-system 110, for example, to write data to the memory sub-system 110 and read data from the memory sub-system 110.

The host system 120 can be coupled to the memory sub-system 110 via a physical host interface. Examples of a physical host interface include, but are not limited to, a serial advanced technology attachment (SATA) interface, a peripheral component interconnect express (PCIe) interface, a universal serial bus (USB) interface, a Fibre Channel, a Serial Attached SCSI (SAS) interface, a double data rate (DDR) memory bus interface, a Small Computer System Interface (SCSI), a dual in-line memory module (DIMM) interface (e.g., DIMM socket interface that supports Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), a Double Data Rate (DDR) interface, a Low Power Double Data Rate (LPDDR) interface, a Compute Express Link (CXL) interface, or any other interface. The physical host interface can be used to transmit data between the host system 120 and the memory sub-system 110. The host system 120 can further utilize an NVM Express (NVMe) interface to access components (e.g., memory devices 130) when the memory sub-system 110 is coupled with the host system 120 by the PCIe interface. The physical host interface can provide an interface for passing control, address, data, and other signals between the memory sub-system 110 and the host system 120. FIG. 1 illustrates a memory sub-system 110 as an example. In general, the host system 120 can access multiple memory sub-systems via a same communication connection, multiple separate communication connections, and/or a combination of communication connections.

The processing device 118 of the host system 120 can be, for example, a microprocessor, a central processing unit (CPU), a processing core of a processor, an execution unit, etc. In some instances, the controller 116 can be referred to as a memory controller, a memory management unit, and/or an initiator. In one example, the controller 116 controls the communications over a bus coupled between the host system 120 and the memory sub-system 110. In general, the controller 116 can send commands or requests to the memory sub-system 110 for desired access to memory devices 130, 140. The controller 116 can further include interface circuitry to communicate with the memory sub-system 110. The interface circuitry can convert responses received from the memory sub-system 110 into information for the host system 120.

The controller 116 of the host system 120 can communicate with the controller 115 of the memory sub-system 110 to perform operations such as reading data, writing data, or erasing data at the memory devices 130, 140 and other such operations. In some instances, the controller 116 is integrated within the same package of the processing device 118. In other instances, the controller 116 is separate from the package of the processing device 118. The controller 116 and/or the processing device 118 can include hardware such as one or more integrated circuits (ICs) and/or discrete components, a buffer memory, a cache memory, or a combination thereof. The controller 116 and/or the processing device 118 can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor.

The memory devices 130, 140 can include any combination of the different types of non-volatile memory components and/or volatile memory components. The volatile memory devices (e.g., memory device 140) can be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

Some examples of non-volatile memory components include a negative-and (or, NOT AND) (NAND) type flash memory and write-in-place memory, such as three-dimensional cross-point (“3D cross-point”) memory. A cross-point array of non-volatile memory can perform bit storage based on a change of bulk resistance, in conjunction with a stackable cross-gridded data access array. Additionally, in contrast to many flash-based memories, cross-point non-volatile memory can perform a write in-place operation, where a non-volatile memory cell can be programmed without the non-volatile memory cell being previously erased. NAND type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

Each of the memory devices 130 can include one or more arrays of memory cells. One type of memory cell, for example, single level cells (SLC) can store one bit per cell. Other types of memory cells, such as multi-level cells (MLCs), triple level cells (TLCs), quad-level cells (QLCs), and penta-level cells (PLCs) can store multiple bits per cell. In some embodiments, each of the memory devices 130 can include one or more arrays of memory cells such as SLCs, MLCs, TLCs, QLCs, PLCs, or any combination of such. In some embodiments, a particular memory device can include an SLC portion, an MLC portion, a TLC portion, a QLC portion, and/or a PLC portion of memory cells. The memory cells of the memory devices 130 can be grouped as pages that can refer to a logical unit of the memory device used to store data. With some types of memory (e.g., NAND), pages can be grouped to form blocks.

Although non-volatile memory devices such as 3D cross-point type and NAND type memory (e.g., 2D NAND, 3D NAND) are described, the memory device 130 can be based on any other type of non-volatile memory, such as read-only memory (ROM), phase change memory (PCM), self-selecting memory, other chalcogenide based memories, ferroelectric transistor random-access memory (FeTRAM), ferroelectric random access memory (FeRAM), magneto random access memory (MRAM), Spin Transfer Torque (STT)-MRAM, conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide based RRAM (OxRAM), negative-or (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM).

A memory sub-system controller 115 (or controller 115 for simplicity) can communicate with the memory devices 130 to perform operations such as reading data, writing data, or erasing data at the memory devices 130 and other such operations (e.g., in response to commands scheduled on a command bus by controller 116). The controller 115 can include hardware such as one or more integrated circuits (ICs) and/or discrete components, a buffer memory, or a combination thereof. The hardware can include digital circuitry with dedicated (i.e., hard-coded) logic to perform the operations described herein. The controller 115 can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor.

The controller 115 can include a processing device 117 (processor) configured to execute instructions stored in a local memory 119. In the illustrated example, the local memory 119 of the controller 115 includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control operation of the memory sub-system 110, including handling communications between the memory sub-system 110 and the host system 120.

In some embodiments, the local memory 119 can include memory registers storing memory pointers, fetched data, etc. The local memory 119 can also include read-only memory (ROM) for storing micro-code. While the example memory sub-system 110 in FIG. 1 has been illustrated as including the controller 115, in another embodiment of the present disclosure, a memory sub-system 110 does not include a controller 115, and can instead rely upon external control (e.g., provided by an external host, or by a processor or controller separate from the memory sub-system).

In general, the controller 115 can receive commands or operations from the host system 120 and can convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory devices 130. The controller 115 can be responsible for other operations such as wear leveling operations, garbage collection operations, error detection and error-correcting code (ECC) operations, encryption operations, caching operations, and address translations between a logical address (e.g., logical block address (LBA), namespace) and a physical address (e.g., physical block address) that are associated with the memory devices 130. The controller 115 can further include host interface circuitry to communicate with the host system 120 via the physical host interface. The host interface circuitry can convert the commands received from the host system into command instructions to access the memory devices 130 as well as convert responses associated with the memory devices 130 into information for the host system 120.

The memory sub-system 110 can also include additional circuitry or components that are not illustrated. In some embodiments, the memory sub-system 110 can include a cache or buffer (e.g., DRAM) and address circuitry (e.g., a row decoder and a column decoder) that can receive an address from the controller 115 and decode the address to access the memory devices 130.

In some embodiments, the memory devices 130 include local media controllers 150 that operate in conjunction with the memory sub-system controller 115 to execute operations on one or more memory cells of the memory devices 130. An external controller (e.g., memory sub-system controller 115) can externally manage the memory device 130 (e.g., perform media management operations on the memory device 130). In some embodiments, a memory device 130 is a managed memory device, which is a raw memory device combined with a local controller (e.g., local media controller 150) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

The controller 115 and/or a memory device 130 can include a proof of space manager 113 configured to manage the unused portion of the storage capacity of the memory sub-system 110 to show proof of space without the help or commands from the host system 120. In some embodiments, the controller 115 in the memory sub-system 110 includes at least a portion of the proof of space manager 113. In other embodiments, or in combination, the controller 116 and/or the processing device 118 in the host system 120 includes at least a portion of the proof of space manager 113. For example, the controller 115, the controller 116, and/or the processing device 118 can include logic circuitry implementing the proof of space manager 113. For example, the controller 115, or the processing device 118 (processor) of the host system 120, can be configured to execute instructions stored in memory for performing the operations of the proof of space manager 113 described herein. In some embodiments, the proof of space manager 113 is implemented in an integrated circuit chip disposed in the memory sub-system 110. In other embodiments, the proof of space manager 113 can be part of firmware of the memory sub-system 110, an operating system of the host system 120, a device driver, or an application, or any combination therein.

For example, the proof of space manager 113 implemented in the controller 115 can manage storage resources, unused by the host system 120, in the memory sub-system 110, generate plots and/or farm plots in the unused portion to participate in activities in a cryptocurrency network, without relying on the computing resources of the host system 120. The host system 120 can be in a low power mode, a sleep mode, or a hibernation mode, while the proof of space manager 113 is sufficient to operate the memory sub-system 110 to participate activities in a cryptocurrency network. Optionally, the proof of space manager 113 can function as a host, specialized for proof of space activities and/or cryptocurrency activities, such that resources in the memory sub-system 110 that are not used by the host system 120 can be used to gain benefits of participating in proof of space activities and/or cryptocurrency activities.

When the memory sub-system 110 is in communication with the host system 120, the host system 120 can send commands to configure the operations of the proof of space manager 113. For example, the host system 120 can provide a user interface that is usable to specify whether the proof of space manager 113 is permitted to operate autonomously without instructions/requests from the host system 120. The permission can be specified by writing data to a register, or a predetermined location or region within a memory device (e.g., 130 or 140) in the memory sub-system 110. Similarly, the host system 120 can write configuration data into the memory sub-system 110 to specify how much, if not all of the unused portion, of the storage capacity of the memory sub-system 110 can be used by the proof of space manager 113 in proof of space activities, when or under what conditions the proof of space activities are permitted, whether plot generation is permitted, whether plot farming is permitted, etc.

Optionally, the proof of space manager 113 can use a network connection without going through the host system 120; and the configuration data can be specified for the proof of space manager 113 via the network connection. For example, the memory sub-system 110 can include an interface for a connection to a network interface card, or a wireless transceiver for a wireless network connection to an access point. The interface is usable by the proof of space manager 113 without the processing device 118 and/or the controller 116 of the host system 120. In some implementations, the memory sub-system 110 can further include a network interface card and/or a wireless transceiver (e.g., for a wired network connection, for a WiFi connection, or Bluetooth connection, or a cellular communications connection); and providing power to the memory sub-system 110 with a connection to the Internet is sufficient to enable the memory sub-system 110 to operate in a cryptocurrency network.

FIG. 2 shows a memory sub-system 110 having firmware 201 to control proof of space activities according to one embodiment. For example, the memory sub-system 110 of FIG. 1 can be implemented according to FIG. 2.

In FIG. 2, the memory sub-system 110 has a memory sub-system controller 115 and firmware 201. The firmware 201 has configuration data 203 and a proof of space manager 113 configured to operate according to the permissions and restrictions specified in the configuration data 203.

The storage capacity 205 of the memory sub-system 110 can include a host allocated storage space 221 and a spare storage space 223.

The host allocated storage space 221 is a portion of the storage capacity 205 explicitly reserved by the host system 120 for use by the operating system and/or applications running in the host system 120. The host system 120 transmits one or more commands to the memory sub-system 110 to reserve the space 221 (e.g., by creating one or more namespaces or partitions of host-specified sizes). The host allocated storage space 221 is not available for proof of space plots and activities controlled by the proof of space manager 113. The host system 120 can send write commands to the memory sub-system 110 to store host data 207 in the host allocated storage space 221.

The spare storage space 223 is a portion of the storage capacity that is not reserved and not used by the host system 120 for storing host data 207 used by the operating system and/or applications running in the host system. The proof of space manager 113 can automatically identify the spare storage space 223 and used it for proof of space activities controlled by the proof of space manager 113, such as generating and storing a plot 209, farming the plot 209 for the cryptocurrency network 217, etc.

The proof of space manager 113 can be configured to use the spare storage space 223 when its storage resources is not required for the operation of the host system 120. When the host system 120 needs a portion of the resources of the spare storage space 223, the proof of space manager 113 can manage the reclaiming of the resources from the plot 209 as if the resources were free and had not been used by the plot 209. Thus, the operations of proof of space manager 113 related to the plot 209 has no impact, or minimized impact, on the host system 120 accessing the resources in the spare storage space 223.

When the host system 120 sends, to the memory sub-system 110, a command to reduce the host allocated storage space 221 (e.g., by deleting a namespace or partition, downsizing a namespace or partition), storage resources freed via the execution of the command become part of the spare storage space 223 usable to support proof of space activities.

When the host system 120 sends, to the memory sub-system 110, a command to increase the host allocated storage space 221 (e.g., by creating a new namespace or partition, enlarging a namespace or partition), the proof space manager 113 can reduce the storage resources used by plots (e.g., 209) to allocate sufficient storage resources to the host allocated storage space 221 (e.g., via deleting a plot 209).

Optionally, the host system 120 can send a command to the memory sub-system 110 to reserve at least a portion of the spare storage space 223 for one or more plots (e.g., 209). The host system 120 indicates to the memory sub-system 110 such a reserved portion is for proof of space; and in response, the memory sub-system 110 can take over the responsibility for managing the portion as part of the spare storage space 223 and/or the de-allocation of the portion when storage resources are needed for host data 207 and/or the host allocated storage space 221.

Optionally, when the memory sub-system 110 is not connected to the host system 120, the firmware 201 can be configured to control the operations of the memory sub-system 110 and the network interface 215.

For example, the firmware 201 running in the memory sub-system controller 115 can detect the connection to a network interface 215 and issue commands to the network interface 215 and the memory sub-system controller 115 in a way similar to the host system 120 using the memory sub-system 110 and the network interface 215. The proof of space manager 113 can use a portion of the storage capacity 205 of the memory sub-system 110 to generate and store a plot 209 that includes proof of space lookup tables 211, and use the plot 209 to generate responses to proof of space challenges. In general, the network interface 215 can be part of the computing system 100, part of the host system 120, or part of the memory sub-system 110.

The storage capacity 205 of the memory sub-system 110 can include the storage capacities of memory devices (e.g., memory devices 130, 140 illustrated in FIG. 1) configured in the memory sub-system 110. A portion of the storage capacity 205 (e.g., host allocated storage space 221) can be reserved for servicing the host system 120 and store host data 207 received from the host system 120. The remaining portion of the storage capacity 205 (e.g., the spare storage space 223) that is not going to be used by the host system 120 for a period of time can be used to store a plot 209. Since the plot 209 is used to store the proof of space lookup tables 211, the storage space occupied by the plot 209 is not available for use by the host system 120 and thus considered the free/spare storage space 223.

To generate the plot 209, the proof of space manager 113 can receive a small amount of initial data and perform computations to compute the numbers in the proof of space lookup tables 211 according to a predefined computing procedure. In general, any algorithms of proof of space can be used; and the implementation of the proof of space manager 113 is not limited to a particular cryptocurrency network (e.g., Chia Network).

To farm the plot 209, the proof of space manager 113 can receive a challenge and use the plot 209 to generate a response that can be easily validated using the small amount of the initial data. The correct, validated response can be seen as a proof that the large amount of data of the plot 209 is stored in a storage space (e.g., in storage capacity 205 provided by memory devices 130, . . . , 140 of the memory sub-system 110).

Optionally, the host system 120 can also run an application to generate plots (e.g., as part of the host data 207) and farm the plots. Thus, the memory sub-system 110 is operable to have two parallel systems for plot generating and farming.

For example, after a namespace is allocated in the storage capacity 205, a logical storage location in the portion of storage capacity 205 represented by the namespace can be referred to via a combination of the namespace and a logical address within the namespace. The memory sub-system controller 115 can map such a logical address in the namespace into a physical address in the memory device(s) 130, . . . , 140 to store data (e.g., the host data 207, or the data of the plot 209).

Optionally, the firmware 201 can be configured to automatically allocate a portion of the storage capacity 205 not used by the host system 120 to one or more namespaces hidden to the host system 120 to store plot 209 controlled by the proof of space manager 113. When the storage resources used by the plot 209 are needed for an operation of the host system 120, the firmware 201 can dynamically delete the namespace used to host the plot 209 and provide the reclaimed storage resources for use by the host system 120, as if it had never been used for storing the plot 209.

Optionally, each plot 209 is hosted in a separate namespace to simplify storage space management and/or reduce or minimize the granularity of namespaces used for plots (e.g., 209). When the storage space currently used by a plot (e.g., 209) is to be used by the host system 120, the proof of space manager 113 can dynamically delete the plot namespace and free up the storage space occupied by the plot (e.g., 209) for the host system 120.

In one implementation, the proof of space manager 113 is implemented via a hardware component, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a System on a Chip (SoC), etc. The memory sub-system 110 can be configured with two host interfaces. One host interface of the memory sub-system 110 is connectable to an external host system 120; and another host interface is connected to the hardware component of the proof of space manager 113. The memory sub-system controller 115 is accessible via any of the two host interfaces to receive read/write commands from the external host system 120 and the proof of space manager 113 respectively.

Alternatively, as illustrated in FIG. 2, the proof of space manager 113 is implemented as part of the firmware 201 running in the processing device 117 of the memory sub-system controller 115. Thus, a portion of the processing power of the memory sub-system controller 115 can be used to execute the instructions of the proof of space manager 113 (e.g., to generate read/write commands related to the plot 209) without a physical host interface between the memory sub-system controller 115 and the proof of space manager 113.

The host system 120 can run an application to provide a user interface 213 to specify and/or adjust the configuration data 203 of the proof of space manager 113. Alternatively, a user device (e.g., a mobile phone, a tablet computer, a notebook computer, a personal computer, a personal media player) can be connected to the network interface 215 to specify and/or adjust the configuration data 203. The network interface 215 can include a transceiver for a wired or wireless network connection, such as a local area network, a wireless local area network, a personal area network, a cellular communications network, etc. The network interface 215 can be connected to a cryptocurrency network 217 that implements a blockchain using proof of space to regulate activities or transactions.

The configuration data 203 can include resource restrictions, allowed activities, account identification, permissions, etc.

For example, resource restrictions can specify a limit on the percentage of the storage capacity 205 of the memory sub-system 110 that is allowed to be used by the proof of space manager 113 to store one or more plots 209.

For example, resource restrictions can specify a limit on the percentage of the computing resources of the memory sub-system controller 115 that can be used by the proof of space manager 113.

For example, resource restrictions can specify a limit on data access bandwidth to the storage capacity 205 that is allowed to be used by the proof of space manager 113.

For example, resource restrictions can specify a limit on program-erase budget of the storage capacity 205 that is allowed to be used by the proof of space manager 113.

When an activity (e.g., plot generation, plot farming) is explicitly specified as one of the allowed activities, the proof of space manager 113 can perform the activities when connected to the network interface 215 and/or the cryptocurrency network 217. Otherwise, the proof of space manager 113 is blocked to prevent the activity that is not included in the allowed activities.

The configuration data 203 can include account identification associated with an account in the cryptocurrency network 217 and/or the plot 209. For example, the account identification can include a cryptographic key used to represent an owner of the account and/or as part of an initial data to generate the plot 209.

The permissions in the configuration data 203 can specify whether and/or when the proof of space manager 113 can operate autonomously. For example, the permissions can be configured to indicate that the proof of space manager 113 is permitted to start operation after receiving an explicit request from the host system 120. For example, the permissions can be configured to indicate that the proof of space manager 113 can operate autonomously when the host system 120 is inactive but cannot operate when the host system 120 is active. For example, the permissions can be configured to indicate that proof of space manager 113 can operate whenever the proof of space manager 113 can access the cryptocurrency network 217.

FIG. 3 shows a memory sub-system 110 having a proof of space manager 113 configured to perform peer to peer transfer of proof of space plots 209 according to one embodiment. For example, the memory sub-system 110 of FIG. 3 can be implemented in a way as illustrated in FIG. 1 and/or FIG. 2.

In FIG. 3, the memory sub-system 110 can use a peer to peer connection 231 with a computing device 241 to transfer a plot 209 to or from the memory sub-system 110.

The computing device 241 can be implemented as a computing system 100 of FIG. 1. Alternatively, the computing device 241 can be a memory sub-system similar to the memory sub-system 110 of FIG. 3, FIG. 2, and/or FIG. 1.

The proof of space managers 113 in the memory sub-system 110 and the computing device 241 can be configured to set up and control the transfer of a plot 209. For example, after the transfer of a plot 209 from the memory sub-system 110 to the storage space 223 in the computing device 241, the plot 209 in the memory sub-system 110 can be erased, discarded, or used to compute a new plot and iterate. For example, a portion of the capacity 205 of a solid state drive can be used to create multiple plots (e.g., one at a time); and the plots can be moved a large capacity hard drive for farming; and the portion of the capacity 205 of the solid state drive used for plot generation can be smaller than the total size of the plots that are eventually generated and transferred to the hard disk drive. In another example, after the transfer of the plot 209 from the computing device 241 to the memory sub-system 110, the plot 209 is no longer stored and/or farmed in the computing device 241.

For example, the proof of space manager 113 in the memory sub-system 110 can decide to dispose the plot 209 stored in spare storage space 223 of the memory sub-system 110 to convert the storage space occupied by the plot 209 into free storage resources. Instead of simply erasing the plot 209, the plot 209 can be transferred to a computing device 241 for reuse. For example, the proof of space manager 113 in the memory sub-system 110 can initiate a peer to peer connection 231 to the computing device 241 to transfer the plot 209 into the storage space 223 of the computing device 241. After the transfer, the plot 209 can be farmed on the computing device 241, subsequently transferred to another device, and/or transferred back to the memory sub-system 110 (e.g., at a time when the memory sub-system 110 has sufficient free storage resources to host the plot 209).

In some instances, the memory sub-system 110 is configured to automatically generate proof of space plots 209. When the computing device 241 has a storage space 223 sufficient for storing and farming a plot 209, the computing device 241 can obtain a plot 209 through transfer, instead of performing computations to generate a plot 209 from an initial set of data. In some scenarios, the computing device 241 can temporarily store the plot 209 for a peer to peer network. After the memory sub-system 110 offers to transfer the plot 209 to the computing device 241, the computing device 241 can acquire the plot 209 through transfer over the peer to peer connection 231. After the transfer, the storage space in the memory sub-system 110 vacated by the plot 209 can be reused (e.g., to generate a new plot, or for allocation to a host namespace).

In general, the peer to peer connection 231 can be established over a bus, a computer network, and/or the Internet, as further discussed below in connection with FIGS. 4 to 6.

When the memory sub-system 110 has a plot 209 that can be transferred, the memory sub-system 110 can provide an indication of the availability of the plot 209 in a peer to peer network. When the computing device 241 has a storage space 223 to host a plot (e.g., 209), the computing device 241 can provide an indication of the availability of the storage space 223 in the peer to peer network. Based on the availability information about plots (e.g., 209) and space (e.g., 223) in the peer to peer network, a peer to peer connection 231 can be established between the memory sub-system 110 and the computing device 241 to facilitate the transfer of the plot 209 from the memory sub-system 110 to the computing device 241.

Similarly, when the memory sub-system 110 has free storage resources for the storage of a plot 209, it can transfer the plot 209 from a computing device (e.g., 241) that offers a plot 209 for transfer in the peer to peer network. Thus, the memory sub-system 110 does not have to perform the computations to generate a plot to occupy the free storage resources.

In one implementation, the memory sub-system 110 can directly control an external network interface 215 (e.g., as in FIG. 2) to establish the peer to peer connection 231. Thus, the peer to peer connection 231 can be established when the host system 120 is not using the network interface 215 and/or the memory sub-system 110, and/or when the host system 120 is in a sleep mode, a hibernation mode, or a low power mode, or without a host system 120 being connected to a host interface of the memory sub-system 110.

In another implementation, the memory sub-system 110 has an integrated communication device 245 (or network interface 215) that is separate from a host interface (e.g., as illustrated in FIG. 5). The proof of space manager 113 can use the integrated communication device 245 (or network interface 215) to establish the peer to peer connection 231 without assistance from a host system 120.

In a further implementation, the host system 120 connected to the host interface of the memory sub-system 110 can establish the peer to peer connection for the memory sub-system 110 using a network interface 215 controlled by the host system 120. Thus, the peer to peer connection 231 can go through the host system 120 in such a implementation.

In some implementations, the peer to peer connection 231 can be established via the memory sub-system 110 and the computing device 241 directly connecting to a common peripheral bus. The memory sub-system 110 can be connected to the peripheral bus using its host interface, as in FIG. 4. With such implementations, it is not necessary for the memory sub-system 110 to have a separate/integrated network interface, direct control of an external network interface 215, and/or a connection going through the host system 120 connected to the host interface of the memory sub-system 110.

FIG. 4 illustrates memory sub-systems 110 and 243 configured for peer to peer transfer of proof of space plots over a peripheral bus 233 according to one embodiment. Each of the memory sub-systems 110 and 243 has a host interface operable for a direct connection to the peripheral bus 233. Through the peripheral bus 233, the proof of space managers 113 in the memory sub-systems 243 can establish the peer to peer connection 231 to transfer a plot 209.

In some instances, more than two memory sub-systems (e.g., 110 and 243) can be connected to the peripheral bus 233. The proof of space managers 113 running in the memory sub-systems (e.g., 110 and 243) can transmit messages via the peripheral bus 233 to each other to indicate availability of plots (e.g., 209) for transfer and availability of storage space (e.g., 223) for storage of plots (e.g., 209).

Alternatively, a host system 120 connected to the peer to peer connection 231 can run an application that obtains the availability information from the proof of space managers 113 running in the memory sub-systems (e.g., 110 and 243) and/or assist the memory sub-systems in establishing the peer to peer connection 231 over the peripheral bus 233.

FIG. 5 illustrates a memory sub-system 110 configured for peer to peer transfer of proof of space plots over a local area network 235 according to one embodiment.

In FIG. 5, the memory sub-system 110 has a communication device 245 that is separate from a host interface 247. A host system 120 can be connected to the host interface 247 via a peripheral bus 233. Since the communication device 245 is separate from the host interface 247 and fully controlled by the memory sub-system 110, the proof of space manager 113 can connect to the local area network 235 without assistance from a host system 120 and/or without the host interface 247 being connected to a host system 120.

The local area network 235 can connect a plurality of devices, such as a computing device 241, the memory sub-system 110, that have proof of space managers 113 running within the plurality of devices. The computing device 241 can be similar to the memory sub-system 110 having a separate communication device 245 in one example, or similar to a computing system 100 of FIG. 1 having a host system connected to a memory sub-system 110. The proof of space managers 113 running in the devices in the local area network 235 can announce their presence in the local area network, broadcast availability of plots (e.g., 209) for transfer, and broadcast availability of storage space (e.g., 223) for accepting incoming plots. The proof of space managers 113 running in the devices in the local area network 235 can establish peer to peer connections 231 to perform plot transfers. The local area network 235 can include wired and wireless network connections; and the communication device 245 can be a wireless transceiver for a network connection to an access point of the local area network 235, or an interface having a port for a wired connection to a router of the local area network 235.

FIG. 6 illustrates a memory sub-system 110 configured in a peer to peer network to facilitate transfer of proof of space plots according to one embodiment.

In FIG. 6, the memory sub-system 110 is connected to a computer network 420 via a network interface 215. Both the network interface 215 and the memory sub-system 110 are connected to a peripheral bus 233 of a computing system 100. A host system 120 of the computing system 100 is connected to a host interface 247 of the memory sub-system 110 via the peripheral bus 233. The peripheral bus 233 and/or the network interface 215 can be part of the host system 120.

In one implementation, the host system 120 controls the network interface 215 and establish a connection to the network 420 for the proof of space manager 113 running in the memory sub-system 110.

Optionally, the proof of space manager 113 of the memory sub-system 110 can control the network interface 215 under certain conditions (e.g., when the host system 120 is in a low power mode, a sleep mode, or a hibernation mode). In such a scenario, the proof of space manager 113 can use the network interface 215 to communicate over the network 420 without assistance from the host system 120 and/or without the host system 120.

Optionally, the memory sub-system 110 can have a separate communication device 245 for a connection to the network 420, in a way similar to the memory sub-system 110 illustrated in FIG. 5.

In FIG. 6, a presence server 251 is configured on the network 420 to provide availability information about plots (e.g., 209) and storage spaces (e.g., 223), and the presence information of devices in which proof of space managers 113 are running. The availability information and the presence information allows the proof of space managers 113 running in the devices to negotiate a transfer, establish a peer to peer connection 231, and transfer a plot 209 over the peer to peer connection 231, as in FIG. 3.

The computing device 241 in FIG. 6 can be similar to the computing system 100 in FIG. 6, or a memory sub-system 110 of FIG. 5.

The configuration data 203 specified for the proof of space manager 113 (e.g., as discussed in connection with FIG. 2) can include permissions and conditions for transfer a plot 209 into, or out of, the memory sub-system 110 and/or conditions and resource restrictions on the use of a peer to peer connection 231 to perform a transfer. The proof of space managers 113 running in the devices can negotiate a transfer within the constraints of their respective configuration data 203, in view of the availability information and presence information collected in the presence server 251.

FIG. 7 shows a method to perform peer to peer transfer of a proof of space plot according to one embodiment. The method of FIG. 7 can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software/firmware (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method of FIG. 7 is performed at least in part by the controller 115 and/or the local media controller 150 of the memory sub-system 110 in FIG. 1, and/or by the processing device 118 of the host system 120. Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated embodiments should be understood only as examples, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. Additionally, one or more processes can be omitted in various embodiments. Thus, not all processes are required in every embodiment. Other process flows are possible.

For example, the method of FIG. 7 can be implemented using the proof of space manager 113 of FIG. 1 and/or FIG. 2 using techniques of FIG. 3 to FIG. 6.

At block 301, a memory sub-system 110 receives configuration data 203.

At block 303, the memory sub-system 110 stores the configuration data 203 for a proof of space manager 113 configured in the memory sub-system 110.

At block 305, the memory sub-system 110 runs the proof of space manager 113 according to the configuration data 203.

For example, the memory sub-system 110 can be a solid state drive having: a host interface 247 configured to receive commands from a host system; memory cells formed on at least one integrated circuit die; and a processing device 117 configured to control executions of the commands.

Optionally, the solid state drive can have a communication device 245, separate from the host interface 247, such as a network interface for a connection to a wired local area network 235, a WiFi transceiver for a connection to a wireless local area network 235, etc.

At block 307, the proof of space manager 113 identifies an opportunity for a transfer of a proof of space plot 209.

For example, the proof of space manager 113 can identify free storage resources available to store the proof of space plot 209. The proof of space manager 113 can communicate the availability information to a computing device 241 directly or indirectly for the transfer of the plot of space plot 209 from the computing device 241. The plot 209 transferred from the computing device 241 can be stored into a storage space 223 provided by the free storage resources. For example, the proof of space manager 113 can farm, in a cryptocurrency network 217, the proof of space plot 209 obtained through the transfer from the computing device 241.

For example, the proof of space manager 113 can transmit one or more messages to a peer to peer network of proof of space managers 113, memory sub-systems 110 (e.g., solid state drives), and/or computing devices 241 to indicate availability of the storage space for accepting an incoming proof of space plot 209.

For example, the proof of space manager 113 can receive, in a peripheral bus 233 or a local area network 235, data representative of a status of the proof of space plot 209 being available for transfer (e.g., from the computing device 241). Further, the proof of space manager 113 can broadcast, in the peripheral bus 233 or the local area network 235, data representative of a status of the storage space being available in the memory sub-system 110 to accept an incoming proof of space plot (e.g., 209) for storage. Through the data exchanged among proof of space managers 113 connected on the peripheral bus 233 or a local area network 235, the opportunity for the transfer of a proof of space plot 209 can be identified.

In other instances, the proof of space manager 113 in the memory sub-system 110 can perform computations to generate the proof of space plot 209 in the memory sub-system 110 and offer the proof of space plot 209 to the device for farming in the computing device 241. For example, after transmitting one or more messages from the memory sub-system 110 to a peer to peer network of proof of space managers 113, memory sub-systems 110 (e.g., solid state drives), and/or computing devices 241 to announce the availability of the proof of space plot 209 for transfer, the memory sub-system 110 can receive a request for the transfer from the computing device 241 that has a storage space 223 to store the proof of space plot 209.

For example, the proof of space manager 113 can broadcast, in a peripheral bus 233 or a local area network 235, data representative of a status of the proof of space plot 209 being available for transfer. After receiving, in the peripheral bus 233 or the local area network 235, data representative of a status of the computing device 241 having a storage space 223 available to accept an incoming proof of space plot for storage, the proof of space manager 113 in the memory sub-system 110 can identify the opportunity for the transfer of the proof of space plot 209 to the computing device 241.

At block 309, the proof of space manager 113 establishes, according to a permission provided in the configuration data, a peer to peer connection 231 to a computing device 241 that is separate from the memory sub-system 110 in which the proof of space manager 113 is running.

For example, the establishing of the peer to peer connection can be in response to a request from the computing device 241 to transfer the proof of space plot 209 to or from the memory sub-system 110, or in response to an announcement from the computing device 241 offering a plot 209 or offering a storage space 223 to store a plot 209.

In some implementations, the proof of space manager 113 communicates with a presence server 251 of a peer to peer network of proof of space managers 113 to identify the opportunity for the transfer of the proof of space plot 209 between the computing device 241 and the memory sub-system 110. The presence server 251 can be configured to receive and provide information of availability of proof of space plots (e.g., 209) and availability of storage spaces (e.g., 223). Based on the information collected and presented by the presence server 251, the proof of space manager 113 running in the memory sub-system 110 can identify the computing device 241 to establish the peer to peer connection 231 that typically does not go through the presence server 251.

At block 311, the proof of space manager 113 transfers, over the peer to peer connection and according to a resource usage restriction specified in the configuration data 203, the proof of space plot 209 between the memory sub-system 110 and the computing device 241.

The computing device 241 can be similar to a computing system 100 having a proof of space manager 113 running its host system 120 and/or memory sub-system 110. Alternatively, the computing device 241 can be similar to the memory sub-system 110 having a proof of space manager 113 running within it.

A non-transitory computer storage medium can be used to store instructions of the firmware of a memory sub-system (e.g., 110). When the instructions are executed by the controller 115 and/or the processing device 117, the instructions cause the controller 115, the processing device 117, and/or a separate hardware module to perform the methods discussed above.

FIG. 8 illustrates an example machine of a computer system 400 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed. In some embodiments, the computer system 400 can correspond to a host system (e.g., the host system 120 of FIG. 1) that includes, is coupled to, or utilizes a memory sub-system (e.g., the memory sub-system 110 of FIG. 1) or can be used to perform the operations of a proof of space manager 113 (e.g., to execute instructions to perform operations corresponding to the proof of space manager 113 described with reference to FIGS. 1-7). In alternative embodiments, the machine can be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and/or the Internet. The machine can operate in the capacity of a server or a client machine in client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or a client machine in a cloud computing infrastructure or environment.

The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), static random access memory (SRAM), etc.), and a data storage system 418, which communicate with each other via a bus 430 (which can include multiple buses).

Processing device 402 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, or the like. More particularly, the processing device can be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device 402 can also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 402 is configured to execute instructions 426 for performing the operations and steps discussed herein. The computer system 400 can further include a network interface device 408 to communicate over the network 420.

The data storage system 418 can include a machine-readable medium 424 (also known as a computer-readable medium) on which is stored one or more sets of instructions 426 or software embodying any one or more of the methodologies or functions described herein. The instructions 426 can also reside, completely or at least partially, within the main memory 404 and/or within the processing device 402 during execution thereof by the computer system 400, the main memory 404 and the processing device 402 also constituting machine-readable storage media. The machine-readable medium 424, data storage system 418, and/or main memory 404 can correspond to the memory sub-system 110 of FIG. 1.

In one embodiment, the instructions 426 include instructions to implement functionality corresponding to a proof of space manager 113 (e.g., the proof of space manager 113 described with reference to FIGS. 1-7). While the machine-readable medium 424 is shown in an example embodiment to be a single medium, the term “machine-readable storage medium” should be taken to include a single medium or multiple media that store the one or more sets of instructions. The term “machine-readable storage medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “machine-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to convey the substance of their work most effectively to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure can refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage systems.

The present disclosure also relates to an apparatus for performing the operations herein. This apparatus can be specially constructed for the intended purposes, or it can include a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the disclosure as described herein.

The present disclosure can be provided as a computer program product, or software, that can include a machine-readable medium having stored thereon instructions, which can be used to program a computer system (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium such as a read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory components, etc.

In this description, various functions and operations are described as being performed by or caused by computer instructions to simplify description. However, those skilled in the art will recognize what is meant by such expressions is that the functions result from execution of the computer instructions by one or more controllers or processors, such as a microprocessor. Alternatively, or in combination, the functions and operations can be implemented using special purpose circuitry, with or without software instructions, such as using Application-Specific Integrated Circuit (ASIC) or Field-Programmable Gate Array (FPGA). Embodiments can be implemented using hardwired circuitry without software instructions, or in combination with software instructions. Thus, the techniques are limited neither to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by the data processing system.

In the foregoing specification, embodiments of the disclosure have been described with reference to specific example embodiments thereof. It will be evident that various modifications can be made thereto without departing from the broader spirit and scope of embodiments of the disclosure as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A method, comprising:

receiving, in a memory sub-system, configuration data;
storing, in the memory sub-system, the configuration data for a proof of space manager configured in the memory sub-system;
running, in the memory sub-system, the proof of space manager according to the configuration data;
identifying, by the proof of space manager, an opportunity for a transfer of a proof of space plot;
establishing, by the proof of space manager according to a permission provided in the configuration data, a peer to peer connection to a device that is separate from the memory sub-system; and
transferring, over the peer to peer connection and according to a resource usage restriction specified in the configuration data, the proof of space plot between the memory sub-system and the device.

2. The method of claim 1, further comprising:

identifying, by the proof of space manager, free storage resources available to store the proof of space plot; wherein the proof of space plot is transferred from the device over the peer to peer connection and stored into a storage space provided by the free storage resources.

3. The method of claim 2, further comprising:

transmitting one or more messages from the memory sub-system to a peer to peer network of proof of space managers, the one or more messages indicating availability of the storage space.

4. The method of claim 3, further comprising:

farming, by the proof of space manager, the proof of space plot in a cryptocurrency network.

5. The method of claim 2, further comprising:

receiving, in a peripheral bus or a local area network, data representative of a status of the proof of space plot being available for transfer; and
broadcasting, in the peripheral bus or the local area network, data representative of a status of the storage space being available to accept an incoming proof of space plot for storage.

6. The method of claim 1, wherein the establishing of the peer to peer connection is in response to a request from the device to transfer the proof of space plot from the memory sub-system to the device.

7. The method of claim 6, further comprising:

performing computations, by the proof of space manager, to generate the proof of space plot in the memory sub-system; and
offering the proof of space plot to the device for farming in the device.

8. The method of claim 7, further comprising:

transmitting one or more messages from the memory sub-system to a peer to peer network of proof of space managers, the one or more messages indicating availability of the proof of space plot for transfer.

9. The method of claim 1, further comprising:

broadcasting, in a peripheral bus or a local area network, data representative of a status of the proof of space plot being available for transfer; and
receiving, in the peripheral bus or the local area network, data representative of a status of the device having a storage space available to accept an incoming proof of space plot for storage.

10. The method of claim 1, further comprising:

communicating, by the proof of space manager with a presence server of a peer to peer network of proof of space managers, the presence server configured to receive information of availability of proof of space plots and availability of storage spaces; and
identifying, by the proof of space manager, the device based on the communicating with the presence server.

11. The method of claim 10, further comprising:

negotiating with the device, by the proof of space manager using the presence server, the transfer of the proof of space plot.

12. An apparatus, comprising:

a solid state drive, having: a host interface configured to receive commands from a host system; memory cells formed on at least one integrated circuit die; and a processing device configured to control executions of the commands;
wherein the solid state drive has firmware configured to: store, in the memory cells, configuration data; identify an opportunity for a transfer of a proof of space plot; establish, according to a permission provided in the configuration data, a peer to peer connection to a device that is separate from the solid state drive; and transfer, over the peer to peer connection and according to a resource usage restriction specified in the configuration data, the proof of space plot between the solid state drive and the device.

13. The apparatus of claim 12, wherein the firmware is further configured to:

identify free storage resources available to store the proof of space plot; and
transmit one or more messages from the solid state drive to a peer to peer network of proof of space managers, the one or more messages indicating availability of the storage space;
wherein the proof of space plot is transferred from the device over the peer to peer connection and stored into a storage space provided by the free storage resources.

14. The apparatus of claim 13, wherein the firmware is further configured to:

farm the proof of space plot in a cryptocurrency network.

15. The apparatus of claim 13, wherein the firmware is further configured to:

receive, via the host interface from a peripheral bus or via a communication device of the solid state drive connected to a local area network, data representative of a status of the proof of space plot being available for transfer; and
broadcast, in the peripheral bus or the local area network, data representative of a status of the storage space being available to accept an incoming proof of space plot for storage.

16. The apparatus of claim 12, wherein the peer to peer connection is established in response to a request from the device to transfer the proof of space plot from the solid state drive to the device; and the firmware is further configured to:

perform computations, by the solid state drive, to generate the proof of space plot in the solid state drive; and
offer the proof of space plot to the device for farming in the device.

17. The apparatus of claim 16, wherein the firmware is further configured to:

transmit one or more messages from the solid state drive to a peer to peer network of solid state drives, the one or more messages indicating availability of the proof of space plot for transfer.

18. A non-transitory computer readable storage medium storing instructions which, when executed in a memory sub-system, causes the memory sub-system to perform a method, comprising:

storing, in the memory sub-system, configuration data;
identifying, by the memory sub-system, an opportunity for a transfer of a proof of space plot;
establishing, according to a permission provided in the configuration data, a peer to peer connection to a device that is separate from the memory sub-system; and
transferring, over the peer to peer connection and according to a resource usage restriction specified in the configuration data, the proof of space plot between the memory sub-system and the device.

19. The non-transitory computer readable storage medium of claim 18, wherein the method further comprises:

broadcasting, in a peripheral bus or a local area network, data representative of a status of the proof of space plot being available for transfer; and
receiving, in the peripheral bus or the local area network, data representative of a status of the device having a storage space available to accept an incoming proof of space plot for storage.

20. The non-transitory computer readable storage medium of claim 18, wherein the method further comprises:

communicating, by the memory sub-system with a presence server of a peer to peer network of memory sub-systems, the presence server configured to receive information of availability of proof of space plots and availability of storage spaces;
identifying, by the memory sub-system, the device based on the communicating with the presence server; and
negotiating with the device, by the memory sub-system using the presence server, the transfer of the proof of space plot.
Referenced Cited
U.S. Patent Documents
8296380 October 23, 2012 Kelly et al.
20060288034 December 21, 2006 Do et al.
20140189890 July 3, 2014 Koeberl et al.
20160330627 November 10, 2016 Zhang
20190108518 April 11, 2019 Asif
20190108519 April 11, 2019 Asif
20190324995 October 24, 2019 Jakobsson
20210271667 September 2, 2021 Cohen
20220043937 February 10, 2022 Spalding et al.
20220116225 April 14, 2022 Cohen
20230139330 May 4, 2023 Lee
Patent History
Patent number: 11856058
Type: Grant
Filed: Dec 14, 2021
Date of Patent: Dec 26, 2023
Patent Publication Number: 20230188599
Assignee: Micron Technology, Inc. (Boise, ID)
Inventors: Luca Bert (San Jose, CA), Joseph Harold Steinmetz (Loomis, CA)
Primary Examiner: Johnny B Aguiar
Application Number: 17/551,024
Classifications
Current U.S. Class: By Stored Data Protection (713/193)
International Classification: H04L 67/1097 (20220101); H04L 67/104 (20220101);