bigchaindb / beps Goto Github PK

View Code? Open in Web Editor NEW

34.0 12.0 23.0 1.25 MB

BigchainDB Enhancement Proposals

Python 12.91% Go 24.71% Shell 62.38%

bigchaindb proposals specs community-project

beps's Introduction

BigchainDB Server

BigchainDB is the blockchain database. This repository is for BigchainDB Server.

The Basics

Run and Test BigchainDB Server from the `master` Branch

Running and testing the latest version of BigchainDB Server is easy. Make sure you have a recent version of Docker Compose installed. When you are ready, fire up a terminal and run:

git clone https://github.com/bigchaindb/bigchaindb.git
cd bigchaindb
make run

BigchainDB should be reachable now on http://localhost:9984/.

There are also other commands you can execute:

make start: Run BigchainDB from source and daemonize it (stop it with make stop).
make stop: Stop BigchainDB.
make logs: Attach to the logs.
make test: Run all unit and acceptance tests.
make test-unit-watch: Run all tests and wait. Every time you change code, tests will be run again.
make cov: Check code coverage and open the result in the browser.
make doc: Generate HTML documentation and open it in the browser.
make clean: Remove all build, test, coverage and Python artifacts.
make reset: Stop and REMOVE all containers. WARNING: you will LOSE all data stored in BigchainDB.

To view all commands available, run make.

Links for Everyone

BigchainDB.com - the main BigchainDB website, including newsletter signup
Roadmap
Blog
Twitter

Links for Developers

Legal

Licenses - open source & open content
Imprint
Contact Us

beps's People

Stargazers

Watchers

beps's Issues

Problem: The current shortnames are weird and hard to use/remember

Problem Description

The current shortnames, such as 4/STANDARDIZE-DC and 6/SWP are hard to use and remember. Do you remember what DC or SWP stands for? Will you remember in a year?

Proposal

In practice, we've actually been using things like BEP4, BEP-4, BEP 4, or BEP#4, because that's much easier to say and to look up. The proposal is just to make that the official "short" way that we reference BEPs.

I think the Python community already does this when they refer to their PEPs, such as PEP-8.

Let's just change all the "shortname" labels to say BEP-N, where N is the BEP number.

Let's also do some searches for "1/C4" and "2/COSS" and replace those with BEP-1 and BEP-2. I think those are the only two shortnames we ever actually used.

Update all references and shortnames in the master branch. See PR #51
Update all references and shortnames in unmerged pull requests, except for PR #57
Update the references and shortnames in PR #57 (the one that creates BEP-11)

BEP Idea: Network-wide consistent max-transaction-size parameter

For a full discussion of this idea and its history, read:

BEP Idea: Add support for IPLD

This was an idea that was originally proposed by @TimDaub in the issue bigchaindb/bigchaindb#485

I created this issue so we don't forget about that idea. For all the comments on that issue, see the issue itself: bigchaindb/bigchaindb#485

Rename this repository?

This repository is currently named "rfc" and the opening line on GitHub says "BigchainDB RFCs."

While using "RFC" is not wrong, it implies a lot of formality and expectations going back to 1969. We want something more lightweight here, I think, so we can move fast.

Ideas

Rename this repository to:

BigchainDB Enhancement Proposals (BEPs), similar to Python
BigchainDB Improvement Proposals (BDBIPs, since BIPs is used already by Bitcoin)

If some of them become very stable and widely-used, then maybe they could be used as the starting point for actual IETF RFCs, something like what Interledger did with some of its specs.

Discuss: BEP-14

The purpose of this issue is to serve as a place to openly discuss the specifics of BEP-14.

Implementing BEP-15

The BEP-15 (Ethereum Integration Tools & Demo 1) has been picked up and being implemented by the BigchainDB Consulting Team.

If any of the community members would like to collaborate on this effort, please reach out to [email protected].

Can transaction.data be a complex structure?

I'm checking the specs, interested on using bigchaindb for health care applications, where clinical documentation is hierarchic (complex trees).

Seen the data spec and it seems a plain key-value list. Is is possible for that to be a general JSON document?

Problem: Unclear what a "Public Contract" is in this context

In 1/C4, the section on "Evolution of Public Contracts" isn't clear what it means by "Public Contracts".

It seems to be talking about BigchainDB Enhancement Proposals, BEPs, but it says that nowhere.

Or is a "Public Contract" something else? Is so, what?

If it's a BEP, can we just change the name in 1/C4 from "Public Contracts" to "BEPs" for clarity and consistency? We could even link to 2/COSS.

Feature Request

We are developing supply chain on blockchain technology. We are using BigchainDb to implement blockchain in our product. Currently we are developing pilot and we are facing following issues:

We want a network where validators of network can just keep data. (We are adding validators only to gain trust of customers). They should not create transaction. There should be a configuration that should prevent validators to create transactions.
Workaround suggestion: Tendermint can implement based on power of validator. If validator have highest or equal to highest power in genesis.json then only can create transaction in network.
Currently any validator can tamper data on their machine by using mongo db query (insert, update and delete) and BigchainDb not implemented any mechanism that can detect those tamper. There should be a mechanism that should detect tamper and should start sync.
Workaround suggestion: You can use hash of collections provided by mongo or can simply generate hash of mongo database and compare with all online validators during insertion of transaction. This is following link for hash https://docs.mongodb.com/manual/reference/command/dbHash/ .
BigchainDb should also watch mongo collection for change query. By doing this BigchainDb will able to prevent tamper on every machine. You can refer this link https://docs.mongodb.com/manual/reference/method/db.collection.watch/
If you are planning to develop a supply chain like product on BigchainDb then a single collection will not able to fulfil all requirements. BigchainDb should give a option to insert data in collection given by user while creating transaction like this:
connection.postTransactionCommit(transactionSigned, {collection: "myCollection"}); // default will be transactions
While getting transaction user will pass collection like this:
connection.getTransaction(transactionId, { collection: "myCollection"}); // default will be transactions collections
We altered asset data in assets collection. As you are storing hash in transactions table that compares data with assets collection data. When I requested from api to get data then response was "Internal server error". You should send some valid response like Data altered in mongo. So that user can know what actually went wrong because one day when i will check my log then i can deduce what actually went wrong and I can take action on this.
There should be a inbuilt authentication mechanism in BigchainDb server api. I know i can disable http request on server and my wrapper (api server) will send request but I think there should be authentication mechanism like AppId and App secret or any other standard authentication.

BEP-11

Has anyone already started developing a Python Driver ORM? If not, then I am ready to take up the development.

Problem: it's not clear how to number BEPs

In 2/COSS I find the following line:

Every BEP (including branches) carries a different number. New versions of the same BEP have new numbers.

It's quite generic, and can lead to arbitrary decisions, what if I want to number my BEP something like π?

I see two different solutions to this problem:

the number is assigned right before merging, incrementing by 1 the value of the last BEP number; or
use the number of the PR.

I lean towards 2), because it's automatically assigned by the platform we are using, and it doesn't require coordination.

BEP Idea: Add MongoDB query and aggregation API endpoint support.

Currently, the asset search endpoint is a basic text search feature which imposes a large computational time to be able to retrieve assets with complex search criteria.
Similarly, asset aggregations have to go through a text search and perform the actual computation on the client side.

This proposal aims to create two new endpoints:

A MongoDB JSON query endpoint which allows a client to perform an arbitrary search on assets. Benefiting from the power of MongoDB search and indexes.
An aggregation query which allows a client to perform aggregations on MongoDB and push the computation to the server.

These new features are implemented in a Pull Request.
BEP Upgrade proposed by Via Science Inc.
Note: Contributors agreement signed.

Problem: Muawia's proposal template is not yet incorporated in our 2/COSS

Over in the bigchaindb/bigchaindb repository, we have an example design specification template (created by @muawiakh with input from others in bigchaindb/bigchaindb#1877 ) but it hasn't been incorporated into 2/COSS in this repository yet.

Potential Solutions

That example design specification template could be included as a separate file in the 2/ directory, or maybe embedded directly in the 2/COSS file.

Note: Be careful about deleting the example design specification template file from the bigchaindb/bigchaindb repository. Some files in that repository might link to it.

BEP Idea: Better handling of consecutive transactions

This idea was originally proposed by @TimDaub in issue bigchaindb/bigchaindb#1789

@TimDaub wrote:

FYI: I'm treating this as bug, as it's a blocker for us on another project.

To simplify our lives, we did not consider in-block ordering of dependent transactions.
We also do not allow two dependent transactions to be in the backlog at the same time (e.g. HTTP API blocks from submitting a TRANSFER where the CREATE doesn't exist yet).

This yields a frustrating problem that we have to patch in several libraries right now, a loop that waits for a transaction to be confirmed, see here or here (loop at bottom of section).

Instead, I'd like to propose fixing this issue with the following changes:

Any schema-valid transaction can pass from the HTTP API into the backlog
Either: The backlog's transactions are topologically ordered, such that when a new transaction gets inserted it gets automatically sorted into place
Or: The backlog is not topologically ordered, such that when a new transaction gets inserted it gets appended to the list of transactions to be processed
Upon block creation the node then:
Either: takes the first 1000 transactions (already topologically sorted) from the backlog and puts them into a block. Caution: This will yield unfair results, e.g. when one transaction DAG is very active
or: takes the first 1000 transactions and sorts them topologically and puts them into a blog

In both cases, this would mean that two (or more) dependent transactions can be in one block.
Bitcoin has this, I remember there was a BIP (can't find it right now). This link might be helpful.

FYI: Topological sorting isn't too difficult (meaning that this task shouldn't be too difficult). There are many ready-made algorithms (I use this one for JS).

BEP Idea: Follower nodes

Add docs, tooling and code to help set up "follower nodes" (or "user nodes"), i.e. nodes which stay in sync with a BigchainDB network, but which can't vote or post new transactions. End users could query them, for example, but they would reject all POST requests (with new transactions). They could have specialized MongoDB indexes for particular use cases.

Use GitHub's new "code owners" feature to assign an owner to each BEP (subdirectory)?

GitHub introduced a new feature that lets you attach owners to files, directories, or the like:

https://blog.github.com/2017-07-06-introducing-code-owners/

Maybe we could try that to give each BEP (e.g. subdirectory such as /5) a code owner?

BEP Idea: Punish proposers who propose bad blocks

For background, see tendermint/tendermint#2175 (comment) including that whole issue, not just the comment.

We must be careful, since proposing a bad block might not mean that a proposer (node) is malicious. In fact, our current code for CheckTx allows a double-spending transaction to get into the mempool, if it came after the last block, and once a transaction gets into the mempool, it soon ends up in a proposed block.

The reason is that our current code for CheckTx assumes the "state of the world" is the state at the end of the last block, not including transactions that have been added to the mempool since then. That will have to be changed if we want to have any hope of detecting truly malicious block-proposers.

BEP Idea: Support Tendermint's ability to filter (block) peers/nodes

A user recently asked how to totally remove a peer/node, i.e. not just set its voting power to zero. Of course you can use a firewall or similar to do that, but the user meant at the Tendermint level. Below is what I learned so far.

I asked on a private Tendermint dev channel, "Is there a way to totally remove a node from a network, rather than changing its power to 0?" The response was a link to this bit of code:

https://github.com/tendermint/tendermint/blob/9e940b95ad4d27efab60d0d49278db5acb2a3b7e/node/node.go#L324-L349

From that, I was able to figure out that it's possible, in some sense, but not documented. You have to do two things:

In config.toml, set filter_peers = true
In your ABCI proxy app (such as BigchainDB Server), you have to implement a response to ABCI "Query" requests to the path:

"/p2p/filter/addr/ip:port"

where ip:port is the address of the peer in question. A path of the form:

"/p2p/filter/id/pubkey"

is also possible.

The response from the ABCI proxy app (BigchainDB Server) tells Tendermint whether or not it's OK to add that peer.

I'm not sure what happens if BigchainDB Server starts responding "not OK" once a peer has already been added. Maybe the query is only done when a new peer is being added?

This is an undocumented feature and the source code has the delightful comment:

	// XXX: Query format subject to change

BEP Idea: Add support for WebHooks

This was issue bigchaindb/bigchaindb#1339 but I copied it here and closed it there.

@vrde wrote:

BigchainDB events API (see bigchaindb/bigchaindb#862) should support WebHooks to enable third parties to trigger their own business logic on specific events. This would fit well because many businesses and developerss are using cloud services like AWS Lambda and AWS API Gateway to build their own applications. A WebHook would be able to trigger custom behaviors on their side, in a """""smart contract""""" fashion.