Package: tinybid
Minimal pure-Python library that implements a basic single-item first-price auction via asecure multi-party computation protocol.PurposeThis library demonstrates how a functionality can be implemented using asecure multi-party computation (MPC) protocolfor evaluating arithmetic sum-of-products expressions (as implemented intinynmc). The approach used in this library can serve as a template for any workflow that relies on multiple simultaneous instances of such a protocol.Installation and UsageThis library is available as apackage on PyPI:python-mpipinstalltinybidThe library can be imported in the usual way:importtinybidfromtinybidimport*Basic ExampleSuppose that a workflow is supported by three nodes (parties performing a decentralized auction). Thenodeobjects would be instantiated locally by each of these three parties:>>>nodes=[node(),node(),node()]The preprocessing workflow that the nodes must execute can be simulated. The number of bids that a workflow requires must be known, and it is assumed that all permitted bid prices are integers greater than or equal to0and strictly less than a fixed maximum value. The number of bids and the number of distinct prices must be known during preprocessing:>>>preprocess(nodes,bids=4,prices=16)Each bidder must submit a request for the opportunity to submit a bid. Below, each of the four bidders creates such a request:>>>request_zero=request(identifier=0)>>>request_one=request(identifier=1)>>>request_two=request(identifier=2)>>>request_three=request(identifier=3)Each bidder can deliver a request to each node, and each node can then locally to generate masks that can be returned to the requesting bidder:>>>masks_zero=[node.masks(request_zero)fornodeinnodes]>>>masks_one=[node.masks(request_one)fornodeinnodes]>>>masks_two=[node.masks(request_two)fornodeinnodes]>>>masks_three=[node.masks(request_three)fornodeinnodes]Each bidder can then generate locally abidinstance (i.e., a masked bid price):>>>bid_zero=bid(masks_zero,7)>>>bid_one=bid(masks_one,11)>>>bid_two=bid(masks_two,2)>>>bid_three=bid(masks_three,11)Every bidder can broadcast its masked bid to all the nodes. Each node can locally assemble these as they arrive. Once a node has received all masked bids, it can determine its share of each component of the overall outcome of the auction:>>>shares=[...node.outcome([bid_zero,bid_one,bid_two,bid_three])...fornodeinnodes...]The overall outcome can be reconstructed from the shares by the auction operator. The outcome is represented as asetcontaining theintidentifiers of the winning bidders:>>>list(sorted(reveal(shares)))[1,3]ImplementationThe auction workflow relies on a data structure for representing an individual bid that is inspired byone-hotencodings. For example, suppose there are six possible prices and four bidders. Each bid can be represented as a list containing sixfieldelements, where each component corresponds to one of the six possible prices.EnsureEach bidder assembles a list in which the component corresponding to their bid price encodes their unique identifier and in which all other entries are 1. The bidders’ unique identifiers are encoded in such a way that the product of any combination of encodings can be decomposed. The table below represents four bids: 3, 4, 1, and 4 (going from top to bottom). In each row, the identifier encoding for bidderiis calculated using the formula 2^(2^(i+ 1)).possible bid prices012345bid from bidder 01112^211bid from bidder 111112^41bid from bidder 212^81111bid from bidder 311112^161The overall outcome of the auction can be determined by (1) performing a componentwise multiplication of the lists and (2) determining which identifiers contributed to the non-1 value with the highest index. The table below presents the entries of the componentwise product of the bids above, the exponents of the entries (which can be computed using, for example,int.bit_length), and the binary representations of the exponents. It is evident that the winning bidders can be inferred by examining the binary representation of the exponent of the non-1 component with the highest index.possible bid prices012345product12^812^22^(4 + 16)1exponent08024 + 160exponent in binary000000100000000000101010000000In order to keep things simple, assume that all bidders have an interest in ensuring that only the winning bids can be determined from the outcome. Under this assumption, the in-the-clear version of the workflow presented above can be modified in a straightforward way to reveal only the winning bidders. In particular, the 1 entries in every list that appearbeforethe bid price component are instead replaced by random nonzero field elements (generated locally by the bidder assembling the bid). This ensures that the overall componentwise product hides all bid information other than the winning bid price and the identities of the winning bidders.In the table below,Ris a placeholder symbol representing various random field elements. Note that any field element multiplied by a random field element (represented byR) yields some other random field element (also represented byR). Thus, in the below product, the only components not masked via multiplication by a random field element are (1) the component encoding the identifiers of the winning bidders and (2) all components corresponding to prices above the highest bid(s).possible bid prices012345bid from bidder 0RRR2^211bid from bidder 1RRRR2^41bid from bidder 2R2^81111bid from bidder 3RRRR2^161productRRRR2^(4 + 16)1Each component of the overall product is calculated using a distinct instance of the protocol implemented bytinynmc. This is accomplished by maintaining multiple distincttinynmcnodeobjects (one for each possible bid price) inside eachtinybidnodeobject. In this way, the bid information is protected both from the auction operator (thanks to the random field elements) and from the nodes (thanks to masking via theMPC protocol).DevelopmentAll installation and development dependencies are fully specified inpyproject.toml. Theproject.optional-dependenciesobject is used tospecify optional requirementsfor various development tasks. This makes it possible to specify additional options (such asdocs,lint, and so on) when performing installation usingpip:python-mpipinstall.[docs,lint]DocumentationThe documentation can be generated automatically from the source files usingSphinx:python-mpipinstall.[docs]cddocssphinx-apidoc-f-E--templatedir=_templates-o_source..&&makehtmlTesting and ConventionsAll unit tests are executed and their coverage is measured when usingpytest(see thepyproject.tomlfile for configuration details):python-mpipinstall.[test]python-mpytestAlternatively, all unit tests are included in the module itself and can be executed usingdoctest:pythonsrc/tinybid/tinybid.py-vStyle conventions are enforced usingPylint:python-mpipinstall.[lint]python-mpylintsrc/tinybidContributionsIn order to contribute to the source code, open an issue or submit a pull request on theGitHub pagefor this library.VersioningThe version number format for this library and the changes to the library associated with version number increments conform withSemantic Versioning 2.0.0.PublishingThis library can be published as apackage on PyPIby a package maintainer. First, install the dependencies required for packaging and publishing:python-mpipinstall.[publish]Ensure that the correct version number appears inpyproject.toml, and that any links in this README document to the Read the Docs documentation of this package (or its dependencies) have appropriate version numbers. Also ensure that the Read the Docs project for this library has anautomation rulethat activates and sets as the default all tagged versions. Create and push a tag for this version (replacing?.?.?with the version number):gittag?.?.?gitpushorigin?.?.?Remove any old build/distribution files. Then, package the source into a distribution archive:rm-rfbuilddistsrc/*.egg-infopython-mbuild--sdist--wheel.Finally, upload the package distribution archive toPyPI:python-mtwineuploaddist/*