{"id":24196524,"url":"https://github.com/dedis/cothority","last_synced_at":"2025-05-16T03:03:53.965Z","repository":{"id":1383517,"uuid":"41791684","full_name":"dedis/cothority","owner":"dedis","description":"Scalable collective authority","archived":false,"fork":false,"pushed_at":"2023-06-28T09:45:09.000Z","size":119713,"stargazers_count":430,"open_issues_count":140,"forks_count":104,"subscribers_count":31,"default_branch":"main","last_synced_at":"2025-04-08T17:16:40.457Z","etag":null,"topics":["cothority","cryptography","decentralized","distributed-systems","secure","trust"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dedis.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2015-09-02T09:13:57.000Z","updated_at":"2025-03-29T18:29:23.000Z","dependencies_parsed_at":"2023-07-05T15:46:04.525Z","dependency_job_id":null,"html_url":"https://github.com/dedis/cothority","commit_stats":{"total_commits":5478,"total_committers":57,"mean_commits":96.10526315789474,"dds":0.6458561518802483,"last_synced_commit":"e0c9afbb847b070e1bda6f54561a4082b803db80"},"previous_names":[],"tags_count":66,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2Fcothority","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2Fcothority/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2Fcothority/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dedis%2Fcothority/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dedis","download_url":"https://codeload.github.com/dedis/cothority/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254459084,"owners_count":22074604,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cothority","cryptography","decentralized","distributed-systems","secure","trust"],"created_at":"2025-01-13T19:35:43.321Z","updated_at":"2025-05-16T03:03:48.956Z","avatar_url":"https://github.com/dedis.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![Build Status](https://travis-ci.org/dedis/cothority.svg?branch=master)](https://travis-ci.org/dedis/cothority) [![Coverage Status](https://coveralls.io/repos/github/dedis/cothority/badge.svg)](https://coveralls.io/github/dedis/cothority)\n\nNavigation: [DEDIS](https://github.com/dedis/doc/tree/master/README.md) ::\nCothority\n\nThis repository is currently maintained by [C4DT](https://www.c4dt.org).\n\n# Cothority\n\nThe collective authority (cothority) project provides a framework for\ndevelopment, analysis, and deployment of decentralized, distributed\n(cryptographic) protocols. A given set of servers running these protocols is\nreferred to as a _collective authority_ or _cothority_. Individual servers are\ncalled _cothority servers_ or _conodes_. The code in this repository allows you\nto access the services of a cothority and/or run your own conode. The cothority\nproject is developed and maintained by the [DEDIS](http://dedis.epfl.ch) lab at\n[EPFL](https://epfl.ch). To read more about cothorites you can have a look at\n[the following paper](https://dedis.cs.yale.edu/dissent/papers/witness-abs/).\n\nThis is an overview of this README:\n- [Documentation](#documentation) with links to different parts of the cothority\n  - [Topically ordered](#topically-ordered) explains the different functional\n    pieces from the cothority from a research point of view\n  - [Network ordered](#network-ordered) gives an overview from a networking point\n    of view\n  - [Links](doc/README.md) collects\n  links to other repositories, papers and webpages that are important to the cothority.\n- [1st steps](#first-steps) giving two example apps ready to use\n- [Participating](#participating-in-the-cothority) on how to help us getting cothority even better\n  - [Setting up your own conode](#setting-up-your-own-conode) describes why you\n    might want to set up your own conode\n\nDon't forget that the cothority is part of a [bigger\nenvironment](https://github.com/dedis/doc/tree/master/README.md).\n\n## Versioning and Roadmap\n\nThe cothority repository is currently being maintained by the factory team\n of https://c4dt.org.\nWe're mostly following semantic versioning, but since DEDIS is not adding new\n features to the project anymore, we suppose that the major version 3 is the\n  last one.\nWhich means that we're trying hard not to break backward-compatibility\n, except for currently unstable features like BEVM.\nFor new features, please wait for https://github.com/dedis/dela to stabilize.\n\nThe Factory team at C4DT has the following plans to be implemented in the\n cothority, which mostly concentrates on ByzCoin:\n- hardening: https://github.com/c4dt/byzcoin/issues/14\n- new features: https://github.com/c4dt/omniledger/issues/211\n\nThe nodes running at https://status.dedis.ch do not use any versioning, but\n are rather deployed once a day using the latest code.\nThis is done in https://github.com/c4dt/byzcoin.\n\nFor the typescript libraries, we do use semantic versioning, as they are\n included by external apps.\nPlease have a look at [PUBLISH.md](./PUBLISH.md) to see how that works.\n\nThe exception to the above are the e-voting binaries which are published\nby tagging a release in this repository. Please have a look at\n[PUBLISH.md](./PUBLISH.md) for information on creating a release for e-voting.\n\n\n### Release v3.1.0\n\nThe release introduces the notion of signature scheme for a given skipchain so that\none can define which co-signing algorithm will be used to sign the forward links. This\nwas necessary in the context of weaknesses in the BLS signature algorithm (see the\n[paper](https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html)). New\nskipchains will be created with [BDN](https://github.com/dedis/kyber/tree/master/sign/bdn)\nset as the signature scheme.\n\nBecause of a new scheme is default, that means that skipchains created after v3.1.0\nwon't work with older versions as they are not aware of the new scheme. However,\nexisting skipchains will continue to operate normally. In summary, if you need to\ncreate skipchains after updating to v3.1.0, make sure every conode is at least using\nv3.0.1 aswell.\n\n### Release v3.2.0\n\nA new field has been added to the *DataHeader*, *Version*, so that new features or\nupgrades can be coordinated between the conodes to only start using it when enough\nof them are up to date. The leader will propose a change of version when it detects\nthat enough of the participants can reach a consensus. A successful increase of\nversion is announced by an empty block that will act as a barrier between the\nprevious and the new version. Its *DataHeader* data will contain the new version.\n\nWhen creating a ledger, the default version is the most recent one and blocks are\ncontinously created with the previous block version until the leader proposes an\nupgrade. Note that the initial version is zero for backwards compatibility.\n\nAnother important change for this version is about how transactions are created as\nthey need to include the ByzCoin version to use the correct hash function. The\ninitial version of the hash was not taking the invoke command into account and it\nhas been fixed for version one and higher. See below examples:\n\nGo\n```go\nclient := byzcoin.NewClient(id, roster)\ntx := client.CreateTransaction(instr1, instr2)\n```\n\nJava\n```java\nClientTransaction tx = new ClientTransaction(instrs, rpc.getProtocolVersion());\n```\n\nJavascript/Typescript\n```javascript\nconst tx = ClientTransaction.make(rpc.getProtocolVersion(), instr1, instr2);\n```\n\n### Release v3.3.0\n\nAn *experimental* contract has been added to ByzCoin making it possible to use\nEthereum contracts. See directory `bevm`.\n\nThe ByzCoin client-side API version number has changed from 1 to 2. Callers\nshould use the new version in their requests, but the change is backwards\ncompatible and old clients will still work.\n\n# Documentation\n\nThe goal of the cothority is to collect projects that\nhandle aspects of collective authorities to support scalable, self-organizing\ncommunities. In this document we present the apps that are directly runnable\nfrom the cothority, as well as links to the services and protocols used in\nthe cothority.\n\nA cothority is a set of conodes that work together to offer collective\nauthority services. This is used to create distributed and decentralized\nservices where no single point of failure can put the whole system in jeopardy.\nConodes communicate with each other using protocols that are short-lived, specific\ntasks with an outcome that can be read by services. Each conode has a set of\nservices that can be contacted through a well-defined API from the outside. The\ncommunication through the API is done with a homebrewn protobuf over websockets\nimplementation.\n\n## Topically ordered\n\nWhen looking at the cothority modules from a topical point of view, we can break\nit up as follows:\n\n```ascii art\n+--------------------------+------------+--------------------------+\n|                          |APPLICATIONS|                          |\n|     Onchain-Secrets      +------------+     Proof of Personhood  |\n|                                                                  |\n|       ByzCoin                 Status            E-voting         |\n+------------------------+---------------+-------------------------+\n|                        |BUILDING BLOCKS|                         |\n| Consensus              +---------------+       Key Sharding      |\n|  - Skipchain                                    - Re-encryption  |\n|  - BFT         General Crypto    Messaging      - Decryption     |\n|  - Collective   - Neff Shuffle    - Broadcast   - Distributed    |\n|    Signing      - RandHerd        - Propagate     Key Generation |\n|                 - RandHound                                      |\n|                                                                  |\n+------------------------------------------------------------------+\n```\n\n### Applications\n\nApplications in cothority use different libraries and are the highest level\nof abstraction in our framework.\n\nHere you get [a list of all applications in the cothority](doc/Applications.md).\n\nThere is one very special application that is considered apart - it's the conode\nitself, which holds all protocols and services and can be run as a service on\na server.\n\n[What a Conode can do for you](conode/README.md)\n\n### Building Blocks\n\nBuilding blocks are grouped in terms of research units and don't have a special\nrepresentation in code. Also, the _General Crypto_ library is more of a\ncollection of different protocols.\n\nHere you get [a list of all building blocks in the cothority](doc/BuildingBlocks.md).\n\n## Network Ordered\n\nIf we look at the cothority from a purely networking point of view, we can\ndescribe it as follows:\n\n```ascii art\n              +-----------------+\n              |CLI, JavaScript, | Frontend\n              |Java             |\n+-------------+-----------------+\n| Conode,     | Services        | Client to Conode\n| Simulations |-----------------+\n|             | Protocols       | Conode to Conode\n+-------------+-----------------+\n```\n\n### Command Line Interfaces\n\nCommand line interfaces (CLI) are used to communicate with one or more conodes.\nAll CLIs need to have one or more conodes installed.\nFor the two CLIs in [first steps](#first-steps), you can use the running conodes\nat EPFL/DEDIS. If you want to test the other CLIs, you might need to set up\na small network (often 3 nodes is enough) of conodes on your local computer\nto test it.\n\nHere you get [a list of all available CLIs in the cothority](doc/CLIs.md).\n\n### Services\n\nEvery app communicates with one or more services to interact with one or more\nconodes. This is a list of available services that can be contacted on a running\nconode. Some of the services are open to all, while others might require authentication\nthrough a PIN or a public key. Most of the apps and services have the same name,\nbut some are not available as an app or have more than one app using it.\n\nHere you get [a list of all available services in the cothority](doc/Services.md).\n\n### Protocols\n\nProtocols are used to communicate between conodes and execute cryptographic\nexchanges. This can be to form a collective signature, create a consensus on a\nnew state, or simply to propagate a new block from a skipchain. Some protocols\nare useful for different services, while others are very service-specific.\nMost of the protocols have a paper that is describing how the protocol should\nperform and that compares it to other protocols.\n\nHere you get [a list of all available protocols in the cothority](doc/Protocols.md).\n\n### Simulations\n\nCothority grew up as a research instrument, so one of its advantages is to have\na framework to create simulations and running them locally or on remote servers.\nSome of the protocols presented here do have the simulation code. Check it out\nhere: [Cothority Simulations](doc/Simulation.md).\n\n# First steps\n\nIf you're just curious how things work, you can check the status of our test\nnetwork or create a collective signature using our running nodes:\n\n## Status\n\nTo get the status of the conodes in the cothority, first install the `status` binary:\n\n```\ngo install ./status\n```\n\nNow you can run it by giving the definition of the dedis-cothority on the command line:\n\n```\nstatus -g dedis-cothority.toml\n```\n\n# Participating in the cothority\n\nThere are different ways to participate in the cothority project. A first step\nis to simply test the different CLI applications in this repository and tell us\nwhat were your difficulties or what you would like to use them for.\n\nA next step is to set up your own conode and participate in consensus\noperations on skipchains or ledgers.\n\n## Setting up your own conode\n\nA conode is a server program that includes all protocols and services. It can\nbe run on a public facing server, but for testing purposes it's also possible\nto set up a network on a machine and only let it be accessed locally.\n\n- [conode](conode/README.md) is the cothority\nserver, a special app that includes all services and protocols.\n- [How to run a conode](conode/Operating.md)\ngives an overview of the environment where a conode can be run\n- [DEDIS-cothority](doc/Join.md)\nexplains how to join the DEDIS-cothority\n\n## Contributing\n\nIf you want to contribute to Cothority-ONet, please have a look at\n[CONTRIBUTING](CONTRIBUTING.md) for our coding practice and\nlicensing details. In short, we use the github-issues\nto communicate and pull-requests to do code-review. Travis makes sure that\neverything goes smoothly. And we'd like to have good code-coverage.\n\n## License\n\nThe software in this repository is put under a dual-licensing scheme: In general\nall of the provided code is open source via [GNU/AGPL\n3.0](https://www.gnu.org/licenses/agpl-3.0.en.html), please see the\n[LICENSE](LICENSE.AGPL) file for more details. If you would like to\nuse Cothority in a way not allowed by the applicable license, please [contact\nus](mailto:dedis@epfl.ch) to inquire about conditions to get a commercial license.\n\n## Contact\n\nWe are always happy to hear about your experiences with the cothority project.\nFeel free to contact us on our\n[mailing list](https://groups.google.com/forum/#!forum/cothority) or by\n[email](mailto:dedis@epfl.ch).\n\n## Reporting security problems\n\nThis library is offered as-is, and without a guarantee. It will need an\nindependent security review before it should be considered ready for use in\nsecurity-critical applications. If you integrate Cothority into your application it\nis YOUR RESPONSIBILITY to arrange for that audit.\n\nIf you notice a possible security problem, please report it\nto dedis-security@epfl.ch.\n\n# Who is using our code?\n\nThis is a list of people outside of DEDIS who is using our codebase for research\nor applied projects. If you have an interesting project that you would like to\nhave listed here, please contact us at [dedis@epfl.ch](mailto:dedis@epfl.ch).\n\n- [Unlynx](https://github.com/lca1/unlynx) - A decentralized privacy-preserving data sharing tool\n- [Medco](https://github.com/lca1/medco) - Privacy preserving medical data sharing\n- [ByzGen](http://byzgen.com/) - Tracking and secure storage of digital and hard assets\n- [PDCi2b2](https://github.com/JLRgithub/PDCi2b2) - Private Data Characterization for [i2b2](https://www.i2b2.org/)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdedis%2Fcothority","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdedis%2Fcothority","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdedis%2Fcothority/lists"}