On the architechture of Circles contracts about circles-contracts HOT 6 CLOSED

Alice can perform a swap by first approving Bobs Person contract for transferFroms of AliceTokens by calling ExchangeApprove and then call the ExchangeTransfer function of Bobs Person contract.

Slight clarification here. I think the function naming is a bit confusing, but I couldn't think of better names. One doesn't need to call ExchangeApprove before an ExchangeTransfer. ExchangeApprove is there in case you want to spend transitively to a contract. With ExchangeApprove you can exchange AToken for BToken spent at contractC without having to first put BToken in your account, and then calling approve( contractC....

from circles-contracts.

The CirclesToken has an owner address specified, which is exempt from requiring approval from token holders to move tokens on their behalf (implemented as an added clause in transferFrom). The owner of all CirclesToken contracts is intended to be the CirclesHub contract... Having a central Hub that is "in charge" of the PersonalToken contracts gives a clear entry point to implement monetary policy. If we want to be able to change the issuance rate or the starting balance, or implement demurrage, we will need a managing entity that has special privileges in the PersonalTokens. I think making CirclesHub be this contract is an easy change.

I think this is the biggest difference that needs to be addressed. Personally, I don't like having this sort of ambient authority as a part of the contracts. I am of the opinion that monetary-policy type things like issuance rate changes and demurage falling to the central locus of authority in the contracts strays from the mission of "connected personal currencies". Is it really a personal currency if an organization can destroy it (i.e. through infinite issuance or infinite demurage) at any point? I think that these sorts of changes could be implemented on the "layer 2" level of the Circles application, with consent of the user. So maybe a user wants to change their issuance rate to near infinity. IMO we should allow this, but no longer call that currency "Circles". (It is removed from the circles-app registry)

from circles-contracts.

I've been stewing too on to what extent the hub architecture can be considered permissioned, and what it makes sense to allow users to do .. aka, to what extent does Circles need to allow users to defend against an adversarial hub?

My proposal would be to have a hub that stores issuanceRate and demurrageRate, the user cannot change these except by participating in a community governance process - but they can fork the hub. We can even create a hubFactory (where anyone can deploy a hub) and a switchHub function, permitted by onlyOwner on each personal currency. True transitive transactions are only permissible between users who share the same hub, though users who don't share the same hub can still transact with all normal erc20 methods.

A system that allows concentration of power is fine if it's also easy to change where power is concentrated.

from circles-contracts.

@ana0 I like this idea. What, are you thinking, is the difference between a Hub and a Validator?

If these are synonymous, I think this changes the flavor of what a validator is (not necessarily in a bad way). Before, a user being validated by multiple "validators" made sense. I don't see how it would make sense to have a user subscribed to multiple hubs.

from circles-contracts.

In practice, at the beginning the idea is to have workshops where people who want can be properly onboarded into the system, where we explain our vision and intentions and we facilitate to let them think of how to design their specific community governance hub (which could be the people who attend the workshop but could be wider). Ideally we want these people to then go on and try to play with the app and add other people in their specific collectives, kinship groups, social organizations, etc.

At the very start, from what Ed says, we would be the only validator. In my opinion, we need a strategy to transition from being the sole validator to facilitating governance processes where there can be a hub/group (defined itself by its interests, values and relationships) who can decide how will they change their issuance rates accordingly. If you are an individual and do not belong to any group, then they are free to do what they please. But there should be a way of letting others know that these people gave themselves one million coins and no groups who they decided to have these rates with.

So the idea is to first try to nurture the commons into being by us actively trying to bring communities together and then have them decide over how they want to govern their money system. In terms of smart contracts, I am not sure if this means moving from Martin to Jakes' architecture. Is there a way to merge the best of both worlds?

What we want to avoid is this super abstract problem of having one issuance rate for the whole world. We need plurality grounded locally, not a universality which is abstracted from each place.

from circles-contracts.

@Jake-Gillberg I've always thought hub and validator are separate roles. Agree it makes sense for a user to be trusted by many validators but have only one hub.

In the old contracts, validator is nothing but an address that is signed up to be a validator, and stores trust relationships like any other. A hub has many possible validators, but otherwise this section of the code seems a lil incomplete/in need of further though. Personally, I like open validators, but think they might need to have reputation. Unclear to me at the moment whether validator reputation could be offchain, but I think maybe yes.

@JuliointheStudio I agree we'll need a transition plan to move away from being the only validator - and I think maybe also from being the only hub, but I think these are probably best kept as different roles.

from circles-contracts.