Difference between revisions of "Comparison"
From IridiaWiki
Jump to navigationJump to search(47 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | = Problem = |
||
⚫ | |||
+ | "How to transfer the sensors readings (quality of the opinion) into a secure dissemination strategy that is similar to the existing approach?" |
||
− | ! Feature !! Classical approach !! Blockchain approach |
||
+ | |||
+ | = Comparison = |
||
+ | |||
+ | == Dissemination == |
||
+ | |||
+ | {| class="wikitable" style="width:100%" |
||
+ | ! Feature |
||
+ | ! Classical approach |
||
+ | ! Blockchain approach |
||
|- |
|- |
||
+ | | Number of used opinions for voting strategy |
||
− | || Num Blocks || 5 || 5 |
||
+ | | Last 2 opinions in robot's memory |
||
+ | | Last 2 opinions in robot's blockchain |
||
+ | |- |
||
+ | | Time |
||
+ | | proportional to sensor readings p, using a sample from an exponential distribution with pg, g = 10 |
||
+ | | see strategies below |
||
+ | |- |
||
+ | | Broadcasting |
||
+ | | During the entire phase |
||
+ | | During the entire phase |
||
⚫ | |||
+ | | Listening |
||
+ | | Only in the last 3s of the phase [1] |
||
+ | | Only in the last 3s of the phase |
||
+ | |- |
||
+ | | Peers |
||
+ | | Send opinions to peers if distance is below 50 cm |
||
+ | | Connect to peers (i.e., to their Ethereum process) if distance is below 50 cm (only in the last 3 s) |
||
+ | |- |
||
+ | | Mining |
||
+ | | Not applicable |
||
+ | | In the last 3s of the dissemination state |
||
+ | |- |
||
+ | | Decision-making strategies: |
||
+ | | DC, DMMD, DMVD |
||
+ | | see strategies below |
||
+ | |} |
||
+ | |||
+ | [1] This is done, such that on average the robot has the same number of neighbors and no time effects are introduced into the system. |
||
+ | |||
+ | == Exploration == |
||
+ | {| class="wikitable" style="width:100%" |
||
+ | ! Feature |
||
+ | ! Classical approach |
||
+ | ! Blockchain approach |
||
+ | |- |
||
+ | | Time |
||
+ | | Sample from an exponential distribution with σ = 10 |
||
+ | | Sample from an exponential distribution with σ = 10 |
||
+ | |- |
||
+ | | Peers |
||
+ | | Do not send/receive messages |
||
+ | | Not connected to any peers |
||
+ | |- |
||
+ | | Mining |
||
+ | | Not applicable |
||
+ | | No |
||
|} |
|} |
||
+ | |||
+ | = Strategies = |
||
+ | |||
+ | === Strategy 1: Amount of transactions === |
||
+ | * Send a transaction with 1 ether in each timestep of the dissemination state |
||
+ | * Expected behavior: The stronger the opinion, the more transactions will be sent; therefore it is more likely that one of these transactions belong to the last two in the blockchain |
||
+ | * Disadvantage: Is this strategy close enough (amount of votes vs. time of dissemination) to the other approach? |
||
+ | |||
+ | === Strategy 2: Direct modulation === |
||
+ | * Send one transaction each time a robot enters the dissemination state, include amount of ether that is proportional to the quality of the opinion |
||
+ | * Expected behavior: Should be very similar to the non-secure version; the last two votes in the blockchain |
||
+ | * Disadvantage: None. Should be directly comparable to the DC strategy. |
||
+ | |||
+ | === Strategy 3: Dissemination time === |
||
+ | * Make dissemination time proportional to the quality of the opinion (i.e., exactly the same as in the non-secure approach) |
||
+ | * Expected behavior: The longer a robot disseminates its opinion, the more likely it is that the transaction gets included in the blockchain (more robots receive the transaction -> more hash power). |
||
+ | * Only listen to other opinions in the last 3s, only mine in the last 3s |
||
+ | * Send voting transaction in the dissemination state using the JSON-RPC interface |
||
+ | * Open questions: When to start the mining process? Does it make sense? Is it a secure approach (i.e., how robust is it to attacks)? |
||
+ | |||
+ | === Strategy 4: Hash-puzzle === |
||
+ | |||
+ | * Robots have to solve a (hash-based) puzzle, whose difficulty is proportional to the quality of the opinion they want to send |
||
+ | * Expected behavior: |
||
+ | |||
+ | === Strategy 5: Most similar === |
||
+ | |||
+ | * Only connect to neighbors in the dissemination state |
||
+ | * The longer a robot is in the state, the more other robots will receive its opinion |
||
+ | * Problem: When do robots mine? Only in the last x seconds (fixed)? Or for a time proportional to their opinion? |
||
+ | * Expected behavior: |
||
+ | |||
+ | == Alternative == |
||
+ | * Use an alternative approach that is not similar to Gabri's approach |
||
+ | * Expected behavior: |
||
+ | * Advantages: Can tailor approach to the blockchain |
||
+ | * Disadvantages: Might be harder to compare the approach and show its advantages |
Latest revision as of 15:36, 31 January 2017
Problem
"How to transfer the sensors readings (quality of the opinion) into a secure dissemination strategy that is similar to the existing approach?"
Comparison
Dissemination
Feature | Classical approach | Blockchain approach |
---|---|---|
Number of used opinions for voting strategy | Last 2 opinions in robot's memory | Last 2 opinions in robot's blockchain |
Time | proportional to sensor readings p, using a sample from an exponential distribution with pg, g = 10 | see strategies below |
Broadcasting | During the entire phase | During the entire phase |
Listening | Only in the last 3s of the phase [1] | Only in the last 3s of the phase |
Peers | Send opinions to peers if distance is below 50 cm | Connect to peers (i.e., to their Ethereum process) if distance is below 50 cm (only in the last 3 s) |
Mining | Not applicable | In the last 3s of the dissemination state |
Decision-making strategies: | DC, DMMD, DMVD | see strategies below |
[1] This is done, such that on average the robot has the same number of neighbors and no time effects are introduced into the system.
Exploration
Feature | Classical approach | Blockchain approach |
---|---|---|
Time | Sample from an exponential distribution with σ = 10 | Sample from an exponential distribution with σ = 10 |
Peers | Do not send/receive messages | Not connected to any peers |
Mining | Not applicable | No |
Strategies
Strategy 1: Amount of transactions
- Send a transaction with 1 ether in each timestep of the dissemination state
- Expected behavior: The stronger the opinion, the more transactions will be sent; therefore it is more likely that one of these transactions belong to the last two in the blockchain
- Disadvantage: Is this strategy close enough (amount of votes vs. time of dissemination) to the other approach?
Strategy 2: Direct modulation
- Send one transaction each time a robot enters the dissemination state, include amount of ether that is proportional to the quality of the opinion
- Expected behavior: Should be very similar to the non-secure version; the last two votes in the blockchain
- Disadvantage: None. Should be directly comparable to the DC strategy.
Strategy 3: Dissemination time
- Make dissemination time proportional to the quality of the opinion (i.e., exactly the same as in the non-secure approach)
- Expected behavior: The longer a robot disseminates its opinion, the more likely it is that the transaction gets included in the blockchain (more robots receive the transaction -> more hash power).
- Only listen to other opinions in the last 3s, only mine in the last 3s
- Send voting transaction in the dissemination state using the JSON-RPC interface
- Open questions: When to start the mining process? Does it make sense? Is it a secure approach (i.e., how robust is it to attacks)?
Strategy 4: Hash-puzzle
- Robots have to solve a (hash-based) puzzle, whose difficulty is proportional to the quality of the opinion they want to send
- Expected behavior:
Strategy 5: Most similar
- Only connect to neighbors in the dissemination state
- The longer a robot is in the state, the more other robots will receive its opinion
- Problem: When do robots mine? Only in the last x seconds (fixed)? Or for a time proportional to their opinion?
- Expected behavior:
Alternative
- Use an alternative approach that is not similar to Gabri's approach
- Expected behavior:
- Advantages: Can tailor approach to the blockchain
- Disadvantages: Might be harder to compare the approach and show its advantages