@agoric/ertp
Version:
Electronic Rights Transfer Protocol (ERTP). A smart contract framework for exchanging electronic rights
277 lines (227 loc) • 12.3 kB
Markdown
User-visible changes in ERTP:
## Next Release
* Purses now support `getCurrentAmountNotifier()` that notifies of balance
changes.
## Release v0.7.0 (21-July-2020)
* Rename `extent` to `value`
* Rename `produceIssuer` to `makeIssuerKit`
## Release v0.6.0 (29-June-2020)
* `purse.deposit()` now returns the amount of the deposit, rather than
the purse's new balance.
* A deposit-only facet was added to purses, and can be created by
calling `makeDepositFacet` on any purse.
## Release v0.5.0 (26-Mar-2020)
Changed most ERTP methods to now accept promises for payments. The
only method that does not accept a promise for a payment is `deposit`,
which only accepts payments.
## Release v0.4.0 (6-Mar-2020)
* We added the concept of a brand, because the assay (renamed to
issuer) was serving two purposes: it was indicating the kind and was
a trusted authority for payment and purse validity. This was a
problem because where it was used to indicate the kind, like in
`payment.getBalance()`, a user could grab an assay from the units,
use it to claim their payment, and think they accomplished something
security-wise.
* Relatedly, most of the methods from payments have been removed. The
only method on payments that remains is `getAllegedBrand`. To get
the current amount of assets in a payment, use the issuer:
`issuer.getAmountOf(payment)`
* makeMint was renamed to 'produceIssuer' to emphasize that the issuer
is most important and the mint is just the admin facet of the issuer.
* ProduceIssuer returns an object with properties like issuer, mint,
amountMath (formerly unitOps), and brand rather than the old version
that just returned a mint.
* Most configuration has been removed from ERTP in favor of a few
built-in configurations: digital assets can be fungible (the
default), or non-fungible. If digital assets are non-fungible, there
is a choice between two settings: 'strSet' mathHelpers handle the
math for extents that are sets of string IDS, and 'set' mathHelpers
handle the math for extents that are sets of more complex objects
(which might be opaque ids called handles or data). Zoe invites use
'set' mathHelpers.
* CoreMintKeeper was rewritten to conserve currency and then inserted
into issuer.js (formerly mint.js)
* We removed the issuer and purse methods with suffix 'All' and
'Exactly' and replaced them with one method per job that takes an
optional amount. If the optional amount is present, the code checks
whether the balance it is working with is equal to that balance.
* The `coerce` method in AmountMath (formerly UnitOps) now only
accepts amounts. This means that minting (i.e.
`mint.mintPayment(moola(3))`) only accepts amounts and rejects raw
extents.
## Release v0.3.1 (4-Feb-2020)
Update dependency on pixel-demo
## Release v0.3.0 (3-Feb-2020)
* Move a number of files out of ERTP and into their own packages in
this monorepo, including:
1. `@agoric/import-manager`
2. `@agoric/make-promise`
3. `@agoric/sparse-ints`
4. `@agoric/insist`
5. `@agoric/registrar`
6. `@agoric/store`
7. `@agoric/weak-store`
8. `@agoric/sharing-service`
9. `@agoric/same-structure`
10. `@agoric/spawner` (formerly contractHost)
11. `@agoric/pixel-demo`
## Release v0.2.0 (12/4/2019)
* Remove Zoe from ERTP and publish as @agoric/zoe
## Release v0.1.12 (11/13/2019)
* Added "myFirstDapp", a smart contract with the same interface as our
autoswap (Uniswap) contract, but which does not have the same
functionality. Instead, the developer building on Zoe is prompted to
add their own custom logic at various points of the contract. By
default, users can use the contract to trade one unit of one kind of
digital assets for one unit of another kind of digital asset
indefinitely as long as they alternate, but this behavior is meant
to be altered by the smart contract developer.
## Release v0.1.11 (11/1/2019)
* Added documentation explaining how the "trait" pattern can be used
to customize the functionality of ERTP interfaces like purses and
payments.
* Fix a race condition in Zoe that occurred when the same assay is
used multiple times in the smart contract's array of assays.
## Release v0.1.10 (10/31/2019)
* Updated how fees are calculated in autoswap so that conservation of
supply is not violated.
## Release v0.1.9 (10/30/2019)
* Added a write up of Zoe and smart contracts. This documentation
now lives at [https://agoric.com/Documentation/](https://agoric.com/Documentation/)
* Cleaned up Zoe and the smart contracts running on Zoe
* Renamed a number of terms:
* descOps -> unitOps
* assetDesc -> units
* conditions/offerConditions -> offerRules
* offerDesc -> payoutRules
* label.description -> label.allegedName
* handoff service to sharing service
* Updated the timer interface to match timerServices
## Release v0.1.8 (10/22/2019)
* Added the registrar naming service. Objects can be registered with a
name. The name supplied by the user is concatenated with a random
string to produce a value like `myName_4409`, if `myName` was the
user-supplied string. Then, this full name can be used to `get` the
object back from the registrar naming service. This can be used to
give public names to objects meant to be shared.
* The contracts that run on Zoe have been updated. There are now six
contracts: `automaticRefund`, used for testing and tutorials, which
just gives the user their digital assets back, `autoswap`, a Uniswap
implementation, `coveredCall` which involves an invite to make an
offer that can act as an option, `publicAuction` which is a
second-price auction, `publicSwap` which has the same swap logic
as the `coveredCall` contract, but which doesn't use invites, and
`simpleExchange` which is a naive decentralized exchange.
* Tests have been written for "higher order" contract uses. That is, a
invite for one contract used as the underlying right in another
contract.
* Exit conditions were added to Zoe. This allows the user to specify
their exit conditions when they escrow an offer with Zoe.
## Release v0.1.7 (10/15/2019)
* Added configurable endowments in contract evaluation for `Zoe` and the
`contractHost`.
## Release v0.1.6 (10/14/2019)
* [Renamed many aspects of ERTP](https://github.com/Agoric/ERTP/commit/a34dad171eb8693b807a7fd959b14e938fedf42a):
1. `amount`, the description of an asset (e.g. 3 bucks), is now
`assetDesc`, short for 'asset description'.
2. `quantity`, the measure of "how much" is in an asset (the '3'
of '3 bucks') is now `extent`. We did this so that we
can reference the extent of non-fungible assets as easily as
fungible assets.
3. `assay`, the operations for manipulating labeled
extents/quantities, is now `descOps`. `DescOps` are the set
operations on asset descriptions. This change makes it clear
that the `descOps` are not an institution in the same sense as
the mint and are merely operations.
4. `strategy`, the operations for manipulating unlabeled extents,
is now `extentOps`. This change makes it clear that it is the
operations on extents, and it acts on extents in the same way
that `descOps` acts on descriptions.
5. Purses and payments are now together called `assetHolders`.
Assets are the intangible (i.e. there is no asset object) erights held by purses and payments.
6. `issuer` has been renamed to `assay`. `assay` and `mint` are
two facets of the same institution. The `mint` has the
authority to create new assets. The `assay` is the
public-facing facet that is often widely known and can be used
to claim exclusive access to a payment or make an empty purse,
among other things.
* Added [support for uploading contracts](https://github.com/Agoric/cosmic-swingset/blob/master/lib/ag-solo/contracts/README-contract.md) at the start of the Agoric testnet.
* Added an [initial version of Zoe](https://github.com/Agoric/ERTP/commit/a32426aab307d31bd0fe1b6e1241d4a270964e31), our offer-safety enforcement layer.
More on this to come.
## Release v0.1.5 (10/4/2019)
* Updated to `@agoric/swingset-vat` v0.0.26. Also updated a number of
other packages.
* Fixed two bugs: `issuer.split` was trying to `vouch` for the amounts
that were passed into the `split` function. When these amounts were
created in a different vat, `vouch` failed. We realized that
`assay.vouch` was unnecessary and `assay.coerce` could be used
instead. The second bug fix was to replace `E.resolve` (deprecated)
with `Promise.resolve` when we did the update of
`@agoric/swingset-vat`.
## Release v0.1.4 (9/3/2019)
Core ERTP:
* Created a "list strategy" for assays. The list strategy allows
non-fungible assets to have set operations. For instance, for the
pixelList assay, each pixel is defined by the x and y coordinates,
but there can be multiple pixels in a purse or payment. These
multiple pixels can be combined together because they are put in a
list. Similarly, we can remove pixels from a purse or payment by
removing them from the list.
* Updated to `@agoric/swingset-vat` v0.0.20 and `ses` v0.6.0
## Release v0.1.3 (8/27/2019)
Core ERTP:
* Extracted assay set operations/arithmetic into "strategies". We had
several different assays that described various types of fungible
and non-fungible digital assets. A lot of the code was reused, but
what differed was the custom logic for the arithmetic or set
operations. For instance, a fungible token just adds or substracts
natural numbers, but a non-fungible token might put something in or
take something out of a list. We extracted that logic such that we
could reuse `assay.js` for many different types of assets.
* Added an 'import manager' that maps strings to imported code. The
import manager allows code such as configuration functions to be
imported rather than passed as parameters.
## Release v0.1.2 (8/20/2019)
Core ERTP:
* Enforced "payment linearity". Whenever a payment is deposited,
burned, or claimed, the entire payment must be used up ("killed").
When a payment is killed, it is removed from the ledger entirely,
not just reduced to an empty amount, as was previously the case. Two
new methods to support payment linearity are added to `issuer`:
`combine(paymentArray)` and `split(payment, amountsArray,
namesArray)`. The methods for depositing are now
`depositExactly(amount, payment)`, which checks that the `amount` is
equal to the `payment` balance, and `depositAll(payment)`. The
methods for burning are now `burnExactly` and `burnAll`, and the
methods for claiming are now `claimExactly` and `claimAll`.
## Release v0.1.1 (8/15/2019)
Core ERTP:
* Made the `makeMint` config act in a more "trait-like" manner.
Instead of creating custom purses and payments by calling a function
that returns the custom purse or payment, the "trait-like" style
combines the core methods of a purse or payment with the custom
methods, overriding any custom methods with the core methods if
there is any overlap.
Pixel Demo:
* Fixed a bug in which `tapFaucet` did not return newly minted
`pixelPayments` but instead returned previously created ones.
## Release v0.1.0 (8/14/2019)
Core ERTP:
* Refactored contracts to make it easier for users to check the terms of
a contract
* Added an IDL to describe the user-facing ERTP interface for mints,
issuers, purses, payments, assays, and the contractHost.
* Renamed `getExclusive` and `getExclusiveAll` to `claim` and
`claimAll`
* Added `equals` as an assay method
Pixel Demo:
* Created a new representation of hierarchical rights for the pixel
demo, which allows holders of higher-level rights to revoke rights
held further down. This follows the pattern of owner, tenant, and
subtenant relationships in real property.
* Made the gallery in the pixel demo use a long-lived contract host
rather than creating a new contract host for each contract
## Release v0.0.9 (7/29/2019)
* Moved ERTP from the SwingSet repository
* Added pixel demo and handoff table to push ERTP design forward to
non-fungible tokens with real uses