Difference between revisions of "Analysis of Data Structures on the Ethereum Blockchain"

From its-wiki.no
Jump to: navigation, search
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Thesis
 
{{Thesis
|Titel=Deliver cloud services without compromising privacy
+
|Titel=Analysis of Data Structures on the Ethereum Blockchain
|User=Jon Ramvi
+
|Supervisor=Josef Noll,
|Supervisor=Gisle Hannemyr, Josef Noll
+
|DueDate=2016/05/02
|DueDate=2015/01/05
+
|ThesisStatus=Finished
|ThesisStatus=Planned
+
|Objective=The web is becoming increasingly more centralized with data congregating towards big players e.g. Google. This is not the decentralized web Tim Berners-Lee envisioned. Having a couple of companies deciding what is 'truth' and what data is available is undemocratizing. It is also endagering peoples [[privacy]]. Centralized data is more valuable to hackers and to government agencies, with the potential value of a successful hack reaching into the millions.
|Objective=Privacy is under constant threat. Companies and governments work hard to track and gather private data. The synergy of combining data in the cloud produces such desirable products that citizens are embracing them at the cost of their privacy.  E.g. facial recognition which can automatically tag all your photos. The same technology can also be used to track your every move around the globe. While a solution is to refrain from adopting technologies that can be used for tracking, is abstaining from the use of social media, search engines and cell phones not a desirable solution for neither end-users nor companies.  
+
 
 +
The web can be re-decentralized with the [[blockchain]] technology. Blockchains allow for [[consensus]] in [[peer-to-peer]] networks, removing the need for centralized servers to decide consensus. The blockchain is how [[Bitcoin]] is able to transfer money without a bank as an mediator. Ethereum allows for [[Turing complete]] applications (called [[smart contracts]]) on the blockchain, giving developers the tools needed to move anything to the blockchain.
 +
 
 +
Miners, special nodes reaching consensus on the network, have to run all smart contracts. With the code in these smart contracts being measured in "gas" instead of [[temporal complexity]] and [[spatial complexity]], means that what we know about the efficiency of different data structures, might have to be revisited. Therefor will this thesis compare various data structures on the blockchain in a theoretical and an empirical manner.
 
|Methods=The tools and methods in this thesis are based on
 
|Methods=The tools and methods in this thesis are based on
* A set of scenario, describing the challenges
+
* A scenario
* A list of requirements being extracted from the scenarios
+
* A list of requirements being extracted from the scenario
* A description and evaluation of technologies and tools being candidates for solutions
+
* A detailed description of the Ethereum blockchain
* A functional architecture/description of the envisaged system
+
* Analysis for various data structures
* An implementation of the core concepts
+
* Implementation of the test bed
* A demonstration of the solution
+
* An evaluation of the study, including a critical review of the decisions taken earlier
* An evaluation of the solution, including a critical review of the descisions taken earlier
+
 
* Conclusions
 
* Conclusions
 
* References
 
* References
|Schedule=The envisaged time schedule (for a long thesis/60 ECTS) is:
+
|Schedule=The envisaged time schedule is:
:T0 0 starting month, T0+m denotes the month where the contribution to a certain chapter shalle be finalized
+
:T0 0 November. Starting month. TOC established. Necessary technologies listed.
:T0+2 months: create an initial page describing the scenario
+
:T0+0: 1 page scenario.
:T0+3: Provide a list of technologies which you think are necessary for the thesis
+
:T0+1: Start of December; Provide a draft of chapter 2: Detailed scenario and requirements, and chapter 3: Description of the Ethereum blockchain
:T0+4: Establish the table of content (TOC) of the envisaged thesis. Each section shall contain 3-10 keywords describing the content of that section
+
:T0+2: January. Establish a draft on what to implement. Set-up an implementation, testing and evaluation plan.
:T0+7: Provide a draft of section 2 (scenario) and 3 (technologies)
+
:T0+4: March. Evaluate your solution based on a set of parameters
:T0+10: Establish a draft on what to implement/architecture
+
:T0+6: May. Deliver the thesis
:T0+11: Set-up an implementation, testing and evaluation plan
+
|Pre-Knowledge=This thesis includes a reasonable amount of programming.
:T0+15: Evaluate your solution based on a set of parameters, keep in mind <i>there is no such thing as a free lunch</i>
+
:T0+17: Deliver the thesis
+
|Pre-Knowledge=This thesis includes a reasonable amount of programming. The envisaged thesis is based on radio communications, thus expects the user to have followed at least two radio-related courses
+
 
|Approved=Pending
 
|Approved=Pending
|Keywords=Privacy, Mobile Security, Information Security
+
|Keywords=Blockchain, Encryption, Confidentiality, Integrity, Availability, Privacy, Information Security, Big-O, Bitcoin
|Depiction=201401Master-Jon_Ramvi.pdf
+
 
}}
 
}}
This page provides hints on what to include in your master thesis.
+
The thesis was abandoned
  
 
= TOC =
 
= TOC =
Title page, abstract, ...
 
 
: 1. Introduction, containing: short intro into the area, what is happening
 
: 1. Introduction, containing: short intro into the area, what is happening
 
:: 1.1 Motivation, containing: what triggered me to write about what I'm writing about
 
:: 1.1 Motivation, containing: what triggered me to write about what I'm writing about
:: 1.2 Methods, containing: which methods are you using, how do you apply them
+
:: 1.2 Scenario Overview
 +
:: 1.3 Research Approaches
 +
:: 1.4 Related works
 +
:: 1.5 Problem Statement
 +
:: 1.6 Proposal for Solution
 +
:: 1.7 Structure of this Thesis
  
: 2. Scenario, optional chapter for explaining some use cases
+
: 2. [[Analysis_of_Data_Structures_on_the_Ethereum_Blockchain/Current_draft#Detailed_scenario_and_requirements|Detailed Scenario and Requirements]]
:: 2.1 user scenario, (bad name, needs something bedre)
+
:: 2.1 [[Analysis_of_Data_Structures_on_the_Ethereum_Blockchain/Current_draft#Scenario|Scenario]]
:: 2.2 Requirements/Technological challenges
+
:: 2.2 [[Analysis_of_Data_Structures_on_the_Ethereum_Blockchain/Current_draft#Technological_challenges|Requirements/Technological challenges]]
  
: 3. State-of-the art/Analysis of technology, structure your content after hardware/SW (or other domains). Describe which technologies might be used to answer the challenges, and how they can answer the challenges
+
: 3. [[Analysis_of_Data_Structures_on_the_Ethereum_Blockchain/Current_draft#Background|Description of the Ethereum Blockchain (State-of-the art)]]
:: 3.1 technology A
+
:: 3.2 technology B
+
  
 
: 4. Implementation
 
: 4. Implementation
:: 4.1 Architecture, functionality
+
:: 4.1 Testbeds
:: 4.2
+
:: 4.2 Description of Prototypes
 +
:: 4.3 Achievements and Prototype Demonstration
  
: 5. Evaluation
+
: 5. Analysis
: 6. Conclusions
+
: References
+
  
= Comments =
+
: 5. Evaluation and Lessons Learned
== Red line ==
+
Your thesis should have a "red line", which is visible throughout the whole thesis. This means you should mention in the beginning of each chapter how the chapter contributes to the "goals of the thesis".
+
  
== Use of scientific methods ==
+
: 6. Conclusions
A thesis follows a standard method:  
+
* describe the problem (''problemstilling'')
+
* extract the challenges. These challenges should be measurable, e.g. method is too slow to be useful to voice handover.
+
* Analyse technology with respect to challenges. Don't write & repeat "everything" from a certain technology, concentrate on those parts (e.g. protocols) which are of importance for your problem
+
  
References
+
: References
* Wikipedia is good to use to get an overview on what is happening. But there is not scientific verification of Wikipedia, thus you should use wikipedia only in the introduction of a chapter (if you use text from wikipedia). Use scientific literature for your thesis.
+
* Scientific library is "at your hand", you can get there directly from UiO: [[How to get access to IEEE, Springer and other scientific literature -> Unik/UiOLibrary]]
+
* I suggest that references to web pages, e.g. OASIS, W3C standards, are given in a footnote. Only if you find white papers or other .pdf documents on a web page then you refer to them in the reference section.
+
  
== Evaluation of own work ==
+
'''[[Analysis of Data Structures on the Ethereum Blockchain/Current draft|Current draft]]'''
Perform an evaluation of your own work. Revisit the challenges and discuss in how you fulfilled them. Provide alternative solution and discuss what should be done (or what could have been done).
+

Latest revision as of 09:17, 28 August 2017

Analysis of Data Structures on the Ethereum Blockchain

by
Supervisor(s) Josef Noll
Due date 2016/05/02
Status Finished
Problem description: The web is becoming increasingly more centralized with data congregating towards big players e.g. Google. This is not the decentralized web Tim Berners-Lee envisioned. Having a couple of companies deciding what is 'truth' and what data is available is undemocratizing. It is also endagering peoples privacy. Centralized data is more valuable to hackers and to government agencies, with the potential value of a successful hack reaching into the millions.

The web can be re-decentralized with the blockchain technology. Blockchains allow for consensus in peer-to-peer networks, removing the need for centralized servers to decide consensus. The blockchain is how Bitcoin is able to transfer money without a bank as an mediator. Ethereum allows for Turing complete applications (called smart contracts) on the blockchain, giving developers the tools needed to move anything to the blockchain.

Miners, special nodes reaching consensus on the network, have to run all smart contracts. With the code in these smart contracts being measured in "gas" instead of temporal complexity and spatial complexity, means that what we know about the efficiency of different data structures, might have to be revisited. Therefor will this thesis compare various data structures on the blockchain in a theoretical and an empirical manner.

Methods and Tools: The tools and methods in this thesis are based on
  • A scenario
  • A list of requirements being extracted from the scenario
  • A detailed description of the Ethereum blockchain
  • Analysis for various data structures
  • Implementation of the test bed
  • An evaluation of the study, including a critical review of the decisions taken earlier
  • Conclusions
  • References
Time schedule The envisaged time schedule is:
T0 0 November. Starting month. TOC established. Necessary technologies listed.
T0+0: 1 page scenario.
T0+1: Start of December; Provide a draft of chapter 2: Detailed scenario and requirements, and chapter 3: Description of the Ethereum blockchain
T0+2: January. Establish a draft on what to implement. Set-up an implementation, testing and evaluation plan.
T0+4: March. Evaluate your solution based on a set of parameters
T0+6: May. Deliver the thesis
Pre-Knowledge This thesis includes a reasonable amount of programming.
Approved Pending by
Keywords Blockchain, Encryption, Confidentiality, Integrity, Availability, Privacy, Information Security, Big-O, Bitcoin
Depiction

this page was created by Special:FormEdit/Thesis, and can be edited by Special:FormEdit/Thesis/Analysis of Data Structures on the Ethereum Blockchain

The thesis was abandoned

TOC

1. Introduction, containing: short intro into the area, what is happening
1.1 Motivation, containing: what triggered me to write about what I'm writing about
1.2 Scenario Overview
1.3 Research Approaches
1.4 Related works
1.5 Problem Statement
1.6 Proposal for Solution
1.7 Structure of this Thesis
2. Detailed Scenario and Requirements
2.1 Scenario
2.2 Requirements/Technological challenges
3. Description of the Ethereum Blockchain (State-of-the art)
4. Implementation
4.1 Testbeds
4.2 Description of Prototypes
4.3 Achievements and Prototype Demonstration
5. Analysis
5. Evaluation and Lessons Learned
6. Conclusions
References

Current draft