or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
tags: cascading-vote-capital
Cascading Vote Capital Mathematical Specification
Created By: Sean McOwen at BlockScience
Types
Definitions of types that would be used to ensure type safety with domains, codomains, etc.
States
The states of the system that could be taken as a snapshot at any time
Global State
User State
Vote State
Stateful Metrics
These are things that can be derived from the state at any point but would not be held as part of the state.
Global State
User State
Vote State
Parameters
Parameters that could be toggled in the system to produce different outcomes.
Vote Parameters
Entities
The entities that need to be represented within the system.
Spaces
The spaces denote payloads that pass through domains and codomains.
UserJoinSpace
The space which denotes the interface for users joining a system
UserLeaveSpace
The space which denotes the interface for users leaving the system
UserEdgeSpace
The space which denotes a source and target user edge
Proposal Vote Space
New Vote Space
Finish Vote Space
Boundary Actions
The definition of different actions that might happen outside of the system such as users joining the system which then need to flow through a chain of actions in the system.
User Join System
Description
The boundary action which triggers a user joining the system
Called By
Followed By
Constraints
User Leave System
Description
The boundary action which triggers a user leaving the system
Called By
Followed By
Constraints
Change Delegate
Description
The boundary action which triggers a change of a user's delegate
Called By
Followed By
Constraints
Vote on Proposal
Description
The action of voting on the current proposal
Called By
Followed By
Constraints
Control Actions
The definition of actions that the system might call, such as an action to update the vote in a circumstance.
Update Active Vote
Description
The system control action which changes what the current active vote is.
Note: How the next active vote is decided is abstracted as outside the system
Followed By
Constraints
Finish Vote
Description
The system control action which starts the chain of ending the vote
Followed By
Constraints
Policies
A definition of the policies that handle all logical things. This could be, for example, a policy which determines under what conditions a user is allowed to join the system.
User Join Policy
Description
The policy which takes care of users joining the system including:
Followed By
Constraints
User Leave Policy
Description
The policy which takes care of users leaving and anything that needs to happen including:
Followed By
Constraints
Change Delegate Policy
Description
The policy which takes care of the logic for switching delegates including:
Followed By
Constraints
Proposal Vote Policy
Description
The policy which accounts for how voting on a policy works including:
Followed By
Constraints
Update Active Vote Policy
Description
Policy for updating the current active vote
Followed By
Constraints
Finish Vote Policy
Description
Policy for finishing the current active vote
Followed By
TBD
Constraints
State Update Mechanisms
Anything that updates state in the system, usually policies will call these with the outputs of logic. The reasoning to split them out is so that if at some point you want to add a recording variable every time an account is changed or do something like have a variable listener, you can just change the mechanism responsible for it in only one place.
Add User Mechanism
Description
The mechanism which adds a user to the global set of users
Inputs
** Logic **
Remove User Mechanism
Description
The mechanism which removes a user from the global set of users
Inputs
** Logic **
Change Delegate Mechanism
Description
The mechanism which changes the delegate for a user
Inputs
** Logic **
Update Active Vote Mechanism
Description
The mechanism which updates what the active vote is
Inputs
** Logic **
Add Vote Mechanism
Description
The mechanism which adds a vote for a proposal
Inputs
** Logic **
Issue Log
What happens when user X has a delegate of user Y, but then Y leaves the system?
Do we need to extend to more than one active voting happening at a time
What if a user tries to leave and they have an active vote already put in?
There has to be tracking of delegation changes at every point if we want to be able to go back to a vote and recreate what happened
This only will work for getting full votes under the assumption of a completely circular and connected systems. If there are pockets of users delegating only within that group, there is of course a risk that no one votes in the pocket and no voting takes place
How likely is it that there will just be a few individuals that all get delegated too, defeating the purpose of even having a cascading vote because there is no possible cascade to take place?
Z Thoughts: