GitHub/quartz
1
0
Fork 2
mirror of https://github.com/jackyzha0/quartz.git synced 2026-03-24 15:05:42 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

vault backup: 2023-02-26 18:35:12

Browse Source
This commit is contained in:
Jet Hughes 2023-02-26 18:35:12 +09:00
parent 2a77eb8dbe
commit bc8b250f4f
1 changed files with 1 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
content/notes/veracity-summary.md
View File

@ -8,7 +8,6 @@ tags:
### Aim
The aim of this project was to consider aspects of a closed public permissioned blockchain. Currently some believe there is an issue with current permissioned blockchains in that they are not sifficiently decentralised. On the other hand open permissionless blockchains such as Bitcoin are cumbersome to use due to their need for an associated cryptocurrency.
### Scenarios
There were three main scenarios that spend time to explore: Adding a new member, removing a member and accidental transactions. This process helped me to understand some of the intricacies of the system I was trying to conceptualise. Before this process I was lost in the infinite number of forms that a solution to our problem count take. By focusing one single aspect of the system I was forced to accept a basic framework of what the solution could be and use it to explore how a given scenario might occur
@ -18,8 +17,6 @@ This was the first scenario I considered. Initally I wanted to explore how a gro
#### Removing a participant
This scenario occurs in two situations. Firstly when a participant wants to leave coluntarily, which can be handled easily, and secondly when a participant or group of participants agree to forcefully remove another participant or group of participants. To accopmlish this we could use a similar system to the add participant but in reverse.
### Solidity Contract
Near the end of the project before my break I decided to try to test the Add New Participant scenario. I decided to do this by making a smart contract that would run on the Iroha Blockchain. I could use the Hyperledger Burrow integration to run a smart contract in the Ethereum Virtual Machine, which could interact with Iroha.
@ -27,31 +24,3 @@ This contract would be called when a new member ==how would it be called?== need
### Security Issues
Dos attack on the chain targeted at the system of adding new participants. By creating numerous request to join the chain, the voting system would become inundated with request and legitamate applicants would be ==hidden?==.
### %%Three tier system
The propsed three tier system consists of an application "lobby", a set of non-voting participants, and a set of voting participants.er system consists of an application "lobby", a set of non-voting participants, and a set of voting participants. %%
#### Process
Stage 1 - understand blockchain and read general literature
Stage 2 - test Hayden's system from last year
Stage 3 - read papers similar to what we are trying to accomplish
Stage 4 - evaluate select scenarios that coild arise with the proposed system, considering how existing technology could be sed and how we could adapt it
Stage 5 - (incomplete) test out ideas for the proposed system in a small scale environment
# %%Plan
- Major points
- reading
- process
- main findings
- scenarios
- solidity contract
- thoughts leading up to it
- what I think it would have been
- what I got implemented
- default contract%%