Lakat: Difference between revisions

From DAO Governance Wiki
Jump to navigation Jump to search
(Added a few questions)
(Questions and content from the original paper in my own words.)
Line 1: Line 1:
Lakat is a shared key-value database of branches and data buckets together with a peer-to-peer protocol that governs the modification of this database. Branches and buckets are added, merged, and pulled through a combination of the Proof-of-Review, broadcasting, and lignification processes. These contributions/changes (submit, review, token and storage) are made by contributors (content contributors, review contributors, token contributors and storage contributors).
A human, or machine can be a contributor while being resistant to Sybil Attacks via the Proof-of-Review process.
There is a graph homomorphism from graph S (submits) to graph B (branches), but not vice versa and there are no homomorphisms between S and graph D (buckets) or B and D.
== Questions ==
== Questions ==
How is this different than DGF?
How is Lakat complimentary to DGF?


* How is Proof of Review different than Proof of Staked Work?
* How is Proof of Review different than Proof of Staked Work?
What problems does Lakat solve?
What problems does Lakat solve?
How are incentives manged by Lakat?
* Integration with tokens as another layer.


What are the principles of Lakat?
What are the principles of Lakat?
How are Sybil attacks prevented?
* Proof-of-Review...DGF solves the Sybil Attack problem with the validation pool, reputation staking, dissuades bad actors with with retroactive reversals.
What is the relationship between bucket and branch?
* The relation between the elementary bucket object and the higher level branch object is not simply a many-to-one relation. Different branches may share some data buckets. See Figure 3 below.
[[File:Lakat-branches-buckets.png|center|thumb|597x597px|Figure 3: A schematic illustration of the two main objects: The branch and the data buckets. A branch typically references multiple buckets and any bucket may be referenced by many branches.]]


== References ==
== References ==


# Horstmeyer, L. (2023). Lakat: An open and permissionless architecture for continuous integration academic publishing. ''arXiv preprint arXiv:2306.09298''.
# Horstmeyer, L. (2023). Lakat: An open and permissionless architecture for continuous integration academic publishing. ''arXiv preprint arXiv:2306.09298''.

Revision as of 09:03, 16 February 2024

Lakat is a shared key-value database of branches and data buckets together with a peer-to-peer protocol that governs the modification of this database. Branches and buckets are added, merged, and pulled through a combination of the Proof-of-Review, broadcasting, and lignification processes. These contributions/changes (submit, review, token and storage) are made by contributors (content contributors, review contributors, token contributors and storage contributors).

A human, or machine can be a contributor while being resistant to Sybil Attacks via the Proof-of-Review process.

There is a graph homomorphism from graph S (submits) to graph B (branches), but not vice versa and there are no homomorphisms between S and graph D (buckets) or B and D.

Questions

How is Lakat complimentary to DGF?

  • How is Proof of Review different than Proof of Staked Work?

What problems does Lakat solve?

How are incentives manged by Lakat?

  • Integration with tokens as another layer.

What are the principles of Lakat?

How are Sybil attacks prevented?

  • Proof-of-Review...DGF solves the Sybil Attack problem with the validation pool, reputation staking, dissuades bad actors with with retroactive reversals.

What is the relationship between bucket and branch?

  • The relation between the elementary bucket object and the higher level branch object is not simply a many-to-one relation. Different branches may share some data buckets. See Figure 3 below.
Figure 3: A schematic illustration of the two main objects: The branch and the data buckets. A branch typically references multiple buckets and any bucket may be referenced by many branches.

References

  1. Horstmeyer, L. (2023). Lakat: An open and permissionless architecture for continuous integration academic publishing. arXiv preprint arXiv:2306.09298.